Thanks Elijah for jumping in. On Wed, 2008-03-05 at 06:25 -0700, Elijah Newren wrote: [...] > I crave the wonderful usability of bzr. In my mind, it's a notch > above the rest. svn and hg aren't too far off, but bzr has some extra > polish. However, it has parallels to svn here in that the format is > going to limit its utility to many people. I was talking to Ian > Clatworthy (bzr dev) about all kinds of bzr and DVCS issues; cool > things in bzr, stuff to put in his writeups, etc. He did his best to > answer questions and sell bzr, but when I pointed out the most obvious > and painful missing feature in bzr that I'd miss the most from using > git -- being a branch container -- there was simply no response. The > ramifications of this single feature are huge, though -- it means much > more than what you'd expect from a single listed feature. In fact, > when you look closely enough, you find that *several* of the features > being developed by bzr in many ways amount to partial workarounds for > this missing functionality. Also, if you read through the bzr layout > model and read over their documentation, you find that their > assumption of branch==directory goes all the way to their very core, > so this will be something that would be extremely difficult for them > to change. And I'd be worried about pushing bzr on the developers of > large and low-level modules, because missing this feature would be > painful to them.
Right. When I started git first I was shocked that I need two clones to keep the stable and the devel branches *around*. But very soon I found that indeed I just want a single clone, and switching branches is so fast that I actually don't mind switching over all the time. And we optimized our autotools stuff to minimize rebuilds needed. > What's the rationale for having everybody use the same thing? I will > likely agree with it, but it is worth noting that some of the reasons > for such a requirement may not be as important anymore. I'll note the > changes in progress already mentioned in this thread to allow > translators to not have to use a VCS at all, and also the existence of > a simple tool called 'mr' which can be used to interact with projects > under half a dozen different VCSes all using the same commands (sure, > you're limited to the lowest common denominator, but that essentially > amounts to the common operations of cvs/svn). Didn't know about 'mr', but always thought about something like that. The only times I've found it's hard to emulate one VCS' behavior with another one is times like a merge failing and needing intervention. Otherwise, the routine things can really be wrapped very easily. > > > - *very* easy to commit to e.g. gnome-2-22 branch, 'trunk', etc > > svn does this in one step, you can turn it into a single step in bzr > (a combined local commit + push; see 'bound branches'), and in hg and > git it will be just two steps (commit + push). > > I don't think this rules out any system. > > > One can write shell scripts that make it very easy to do so... We can > > Bah! "The tool is broken but I know how to work around it". > > The tool is stupid and lacking if you have to do this, IMO. Well, there are as many different workflows as there are users. A tool having one command for each of them is not necessarily the most flexible and better one. If a workflow is logically divided into multiple steps: - Checkout the gnome-2-22 branch - Edit the .po file - Commit it - Fetch any possible remote changes, rebase - Push it out and if the user can't be bothered to run three commands, I don't see why a shell script is stupid. I have a shell script in my cairo tree, called 'g', that does: git fetch cairo git rebase cairo-origin Sure, one may go lobby for calling that git-update. For me, it does the job, and I better understand what's going on. The above is kinda non-standard. A more standard version would be: git fetch origin git rebase origin/master that's pretty much equivalent to 'svn update'. > I haven't looked at the bindings side myself, but from what I've read > bzr would be the winner here, then hg, and git doesn't have much of > anything at all. (git is really nice from a shell scripting side...in > fact, it seems like it was designed for someone else to write a > wrapper around it...oh, wait, it was. Too bad no one has made a good > one yet and published it) That's not true. Tim Janik has published one for example, called YummyYummySourceControl: http://blogs.gnome.org/timj/category/tools/ > Elijah -- behdad http://behdad.org/ "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin, 1759 _______________________________________________ Gnome-infrastructure mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-infrastructure
