On Fri, 4 Feb 2011 19:02:20 +0100 <J.B.C.Engelen@...1578...> wrote:
(I have become to hate bzr with quite some passion, so my arguments may be biased.)
:-} that's very honest, anyway - I guess it's only a form of bias if it leads you to count things against bzr unfairly.
Personally I use bzr mostly from the command line, but I do sometimes use the QBzr http://wiki.bazaar.canonical.com/QBzr pseudo-gui, invoked for example as
bzr qcommit
These are just some minor factoids in case they're helpful, assuming (?) that a switch from bzr to SVN is unlikely.
- the qcommit interface will show you non-versioned files
also, have you looked at Bzr-explorer, which comes with the standalone windows bzr install?
- No fixed revision numbers?!
- revision IDs are fixed, they're strings like
'tbrown@...2561...'
which are of course less appealing than simple numbers, but simple numbers aren't really possible in a distributed peer-to-peer system. Although having said that I thought Ted applied a setting to the lp repo so that subsuming other people's commits into a merged commit of your own is not possible, so lp rev no.s should be fairly fixed.
- when an operation fails halfway, 50% chance of the tree being damaged,
and completely new checkout needed, which takes a long time and can again fail halfway...
You can use shared repositories to avoid slow checkouts. Create a directory with bzr init-repo and then branch the lp trunk in there. Afterwards you can delete the trunk branch and branch it again and it should take long at all. I don't use the windows gui bzr tools much, but I know one of them, probably bzr-explorer, asked me about wrapping a branch in a shared repo when I went to branch something the other day.
bzr supports multiple distinct workflows, I'm sure things could get confusing if you were mixing parts of different workflows. Personally I only use branch/merge/pull/push, I forget the checkout/update/commit semantics, although I suspect those are closer to SVN style.
Cheers -Terry