-----Original Message----- From: Terry Brown [mailto:terry_n_brown@...36...] Sent: 04 February 2011 19:47 To: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] bzr rant... Was: Updated 2geom -- what changed?
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.
Now that we have used bzr for a little over a year, perhaps we can do a poll / evaluation?
- the qcommit interface will show you non-versioned files
This is the commit dialog that I use (right-click in explorer)
also, have you looked at Bzr-explorer, which comes with the standalone windows bzr install?
Yes I have. It is slow and is not a good replacement for file browsing with explorer.
- 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.
Is there any way to quickly go to, say, rev ' goejendaagh@...2563...'? (i.e. does it make sense to provide that revision name or not)
so lp rev no.s should be fairly fixed.
How fairly is fairly? I want to be able to refer to unchanged rev numbers after several years.
- 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.
I have my tree like that (per Inkscape wiki help). I think you can only quickly (i.e. no internet) branch from an existing branch on the pc? If I delete the trunk branch, what would be the command to quickly branch a new trunk branch? Do I need two trunk branches to do that?
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.
I exclusively use checkout/update etc in SVN style workflow. Very few people use branches for Inkscape (check Inkscape's launchpad page) as it usually does not make sense, and you miss out on other people testing what you code. So, the way I see it, we changed to a versioning system that seems oriented to a task that is desired roughly 10 times per year.
Ciao, Johan