Christian Heimes wrote: > Martin v. Löwis wrote: >> I would like to ask the same for any conversion *from* subversion, >> be it to hg, bzr, git, bk, or ClearCase. >> >> So anybody who wants to seriously attempt introducing such a change, >> please present your PEP. Anybody else, please stand back and watch. > > I also like to some good answers for a bunch of questions. > > What are the benefits and strengths of bzr/git/hg better over svn? What > problems do the distributed version control systems solve that svn > doesn't solve.
Intelligent (I'd say "functional", but most people seem to be more forgiving than me) branching and merging. On merging, they all can merge two branches together while preserving history. You don't lose history, and you don't have to keep track of revision numbers for repeated merges. All you have to do is "$vcs merge" and the VCS will work out which revisions need to be merged. On branching, every checkout is really its own branch. (That might sound complicated, but it's not. If you just want to keep a copy of another branch, all you have to do is e.g. "hg pull -u" instead of "svn up".) This means that you don't have to have commit access to the central server to make your own branch and commit to it. After working privately, you can publish your branch (also much easier to do than in svn), or generate a patch-like file, and other people or the central developers can easily merge your changes, preserving history. That also means that developers can create tons of small branches without making a mess of the central server (just their own ;-) ). Those three also have three different rename handling designs, all more advanced than svn's basic copy+delete. (Checkouts being branches, (usually) with the full history downloaded, also means you can diff or annotate or commit or whatever you want while offline, useful on a train or whatever.) > Why should we choose bzr/git/hg over bzr/git/hg? Mostly (going on their general reputations): Git is a speed demon, but has a horrible, complicated UI (which has recently been improving). It's also only recently started to get decent Windows support. Bzr has a nice UI and is cross-platform (and has great dumb server (HTTP, SFTP, FTP) support), but is slow (not a problem on non-huge projects, and it's getting better). Hg is cross-platform, almost as fast as git, and with nice UI. Git is written in C (with some shell scripts and stuff that are being rewritten in C). Bzr and hg are both written in Python with some C bits for performance. (I prefer bzr's UI to hg's. Hg uses more technical and lower-level terms than really necessary, and bzr doesn't. Not a major problem, though. Hg might even promote a better understanding of the tool, which would be nice. Hg also has a simpler UI and tends to have minimal (or no) output, e.g. you have to supply -v to commit just to get the list of files modified; by default it outputs nothing.) > Do the new feature justify the extra burden on the core developers to > learn a new VCS and new tools? Once everybody switches to bzr/git/hg, that won't be a problem anymore! :-D Well, the core developers don't experience one of the main disadvantages of svn: that non-core developers don't have the ability to make their own branches or commit. But I would still say that the more branchy and history-preserving workflow is absolutely worth it. (Of course, with less technical teams, having to learn even one more term is practically a deal-breaker. But that shouldn't be a problem among an FOSS programming language's developers...) > Does a new VCS come with all the nifty and handy small tools, OS > integration and IDE integration I like? I definitely don't want to loose > the explorer integration of tortoisesvn on Windows or meld on Unix. The > new VCS may have reached version 1.0 but do they come with the rich tool > set? Although I'm a CLI fetishist I still like a decent GUI for some tasks. For bzr and hg (and I presume git), not yet. The GUI and tool situation is getting better all the time, but it still isn't as good as Subversion. A lot of tools are available now, but they aren't that mature. > Christian As a disclaimer, I should say that I'm not a big-time programmer, but I am a nerd who is very interested in VCSes and does use them. I've also never used git, but I use both bzr and hg a lot, chat with their developers on IRC and have even written a few tiny patches. Err, when did this become a big discussion on VCSes? I didn't really mean to do that, but I can't resist pushing DVCSes whenever I get the opportunity. :-P Ok, I'm really tired of working on this message now. And when I make changes, I'm just hacking them in without reworking the surrounding text much. So I'll hit Send now. I haven't seen a basic, practical, "vs.-svn" sort of introductory article on DVCSes. I wish there was one, because I'm sure it would sound better than anything I could come up with. :-P -- _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
