Selena loves Git and I love Bazaar. And like all good nerds we've spent a fair amount of time talkin' smack about the other's version control system. And I say "all good nerds" because Sam and I tend to "fight" about version control systems at DrupalCon as well (alcohol is optional, but hand waving is mandatory). See in the back row of that photo? It's Victor Kane. His new book, Leveraging Drupal, also talks about version control systems for Drupal.
After a little bit of discussion (and after I stole Selena's git slides to give a bzr talk) Selena and I decided that maybe there ought to be a conference presentation on how to choose the best version control system for your work environment.
Like all good things open source this presentation is going to be built under the release-early-release-often model. It's not a place to talk smack though. It's a place to talk about how you should go about evaluating a version control system for your work environment and it's hosted at www.bzrvsgit.com and/or www.gitvsbzr.com. If you want to have your ideas added to the list, please tweet or dent using the hash tags #bzr, #git, #bzrvsgit or #gitvsbzr. Got something longer to say? Blog it and then tweet/dent it with a link to your blog post!
Our list of community contributed topics currently includes:
- CrashTest_: You know, I am sold on bzr, however I haven't yet figured a way to incorporate VCS into my workflow correctly. Confused.
- sdboyer: ooh, #bzrvsgit - i want use case comparisons, ie, "Exporting the current tree," and compare possible gui/cli approaches
- thesethings: You have to acknowledge how tools "up the stack" (Iike clients, github,launchpad) greatly influence the decision. #bzrvsgit
- mikl: well, I suppose that’s mainly a speed vs. features comparison, so both of those :) #bzrvsgit
- datawench: i'm currently using nothing, but haven't really hit a situation yet where it shouted its necessity. am edging toward, though
We'll be checking the official Web sites for Git and Bazaar for these answers. That means both projects will end up stronger (and with better Web sites) as a result of your questions. Start asking now and let's make version control easier for everyone no matter which platform they choose!
PS We want to help you choose the right version control system. The answers may lead you to use something other than Bazaar or Git. Tweet/dent your questions using the hashtag #vcs if you are feeling anti-#bzrvsgit.
i vote for git
i vote for git :-)
http://raincitystudios.com/blogs-and-pods/roland-tanglao/git-drupalers-2...
It's not just what you vote
It's not just what you vote for, but how you make the decision on which VCS you should vote for. What questions did you ask of yourself/your team and the VCS communities? What tests did you perform and what metrics did you use?
Open source is all about the freedom to choose, but if we don't know HOW to choose then there is no freedom.
All valid points! I vote for
All valid points! I vote for git for my personal drupal work. I don't speak for the drupal community of course :-) ! And in fact, I think drupal should move from CVS to something else but I don't know what else. My heart says NOT svn and it should be git or bzr but I have no data to back that up.
I used git because of github.com and the many many tutorials about git and the fact that the vancouverites in our admitedly small tech community use git and not bzr.
bzr vs. git is the new Emacs
bzr vs. git is the new Emacs vs. Vi.
They both do very similar things, and people feel strongly about the specific ones they use.
For an open source project, where you want multiple versions of the truth (no central repository), the distributed VCS's out there do the job (git, bzr, hg, ...etc.)
One decision point is that git lags a bit in the "clients for Windows" division. bzr is a bit ahead here. So if your projects user base are Windows users, this is one thing to consider.
For a company with coordinated releases to clients a centralized VCS's still do the job (e.g. subversion). Not every use case requires a DVCS.
But sooner or later, DVCS's will take over, since they can still be used centrally.
Who will be the winner? Let us way and see.
as always :-), what khalid
as always :-), what khalid said!!!
I'm not impressed by git's
I'm not impressed by git's inhuman manuals and github's mac appeal & in-your-face commercialization, so not really a fan of it. Fine to work with in a project, but in a personal one, bzr, simply because they value time and getting to the point.
After spending all week
After spending all week trying to determine between the two, I have to give the nod to bzr. Git is definitely cool as hell (- I am an old time cvs guy that moved to svn for the last few years), but the pita setting up a central repository was driving me crazy! Once I tried the sftp push in bzr, it was game over for git (even though the version flipping back and forth thing was a strong one in favor of git).
http://www.joelonsoftware.com
http://www.joelonsoftware.com/items/2009/03/09.html
Joel, as always, hits the points home: "Lacking a program manager, your garden-variety super-smart programmer is going to come up with a completely baffling user interface that makes perfect sense IF YOU’RE A VULCAN (cf. git). The best programmers are notoriously brilliant, and have some trouble imagining what it must be like not to be able to memorize 16 one-letter command line arguments. These programmers then have a tendency to get attached to their first ideas, especially when they’ve already written the code."
The people who like git are super-extra-power-nerds and/or people who have invested heavily in learning it. The reason why it is often wrong for a project, especially say one like GNOME, is that it raises the bar unnecessarily high for new contributors and even higher for any non-programmers or other technical people. Does your project want other contributors, say for documentation, artists or similar? Or even just make it easy to help out? Then choose something that doesn't require a Vulcan. That is all.
i think he's got a great
i think he's got a great argument but doesn't it apply equally to bzr? or heck cvs for that matter.
I don't tweet unless I ride
I don't tweet unless I ride my bike too fast through flocks of small birds, and while I do dent, I only use it for communicating with immovable objects, so I will put my criteria here in these comments. You can try to deny me by requiring obtuse communication protocols, but I will route around it, by damn!
The key element for DVCS tools for me is that I usually start a project before I realize it is going to change enough (i.e. more than twice) to need version control. So, the key criteria is, when I do an initial import, does it work?
cvs - doesn't like binary files (these happen... a lot - images, requirements docs, databases - they all get versioned)
svn - works fine, until it doesn't - I tried versioning my existing email - it barfed with no explanation
git - it "Just Didn't Work" on my proposed repo - errors and confusion, even though I am a Vulcan (that means made of rubber, right?)
bzr - a nice toolset, and "Just Works" on most projects
mercurial - also nice, quite fast, I have seen no downsides, but my friend Aaron Bentley didn't write it, so I don't use it much
rdiff-backup - not a DVCS, but for simple tracking of massive(ly) mixed data, TOTALLY FANTASTIC, and the shouting is completely justified.
I would like to see
I would like to see Mercurial join the discussion. I don't have as much experience using various VCSs as others out there, but Mercurial struck me as the easiest for mere mortals to use.
No matter how cool git and
No matter how cool git and bzr are, svn is still the most widely used VCS; people are familiar with it and the available tools are stable. Both git and bzr integrate with svn repositories (tried both), but bzr does so in a much more seamless way (bzr just works with svn repositories or checkouts, git needs to branch and push/pull changes with git-svn). Using bzr in a non-decentralized fashion is also almost similar to using svn.
When working on projects with other developers, I generally set up a svn repository to which they can connect using their favorite tools. On my side, I do a bzr checkout from the svn repository, which gives me all the advantages of bzr without forcing other people to use it.
Here is a one type of
Here is a one type of metrics, namely how actively CVS, SVN, Git, Bzr and Mercurial are used by Debian GNU/Linux users:
http://qa.debian.org/popcon-graph.php?packages=cvs%2Csubversion%2Cgit-co...
The popularity is measured from atime value changes of the files included in the Debian software packages. Not perfect but it gives some pointer. Currently it shows that SVN is the most commonly used, Git is just about to overtake CVS, and Bzr and Mercurial are quite marginal (but are still growing slowly).
I just found this page,
I just found this page, about migrating from svn to a dvcs. Could be useful - I haven't finished reading it yet:
http://www.python.org/dev/peps/pep-0374/
Hi, I'm evaluating bzr right
Hi,
I'm evaluating bzr right now and right now just hoping I won't get stuck.
This post below from http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html
kind of worries me, anyone with brz-experience to pin the issue down?
//thanks
POST FROM http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html
I'd just like to say, after using SVN and BZR for a while. Bazaar bites. Sorry. It's just extremely frustrating to use. Sometimes it makes it nearly impossible for someone to get the latest code.
Say you change a file on your machine, but you don't want to commit it, you want to delete it and get the latest update. Good luck. Bazaar will make you work and do run arounds to get the latest code, because it tells the user "You have an up-to-date copy of revision 12" when its really revision 18 or so. Now you have to do a revert, then a merge, no that didnt work, still at r12... now give up and delete everything and get a new branch out. Dont even get me started on using a revert on a subdirectory - it will revert your ENTIRE tree and fry any other code changes. WTF, Bazaar? This program is definitely not easy to use, because there are way too many obscure commands needed to do simple things. There just is no bzr equivalent to "svn update", and that is a huge, major, glaring omission.
SVN wins the ease-of-use category, hands down.
Granted I havent used Bazaar on a very large project and I'm guessing that's where it's strength lies. Otherwise, I hate the stupid thing.
END POST
Well, what can we reply an
Well, what can we reply an anonymous commenter who clearly did not spend more that a couple of minutes learning bazaar and draws conclusions from his preconceptions. Even the tutorial says that, to revert specific files or directories, one must give them on the command line http://doc.bazaar-vcs.org/latest/en/tutorials/tutorial.html?highlight=re...
About the alleged problem of "bzr merge" not merging the latest changes, he does not give enough detail to understand his misconceptions. Maybe, he just should read http://doc.bazaar-vcs.org/latest/en/user-guide/zen.html?highlight=revision number ?
In any case, I have been using bzr for some time now and it is much easier to use than SVN (even for interacting with SVN repositories — which bazaar does transparently thanks to the bzr-svn plugin http://bazaar-vcs.org/BzrForeignBranches/Subversion —, especially when creating and merging several branches on those).
Instead of relying on the opinion of such people whose level of expertise can be questioned, go to http://bazaar-vcs.org/BzrSupport and ask your questions to the ones who actively use bazaar. The community is friendly and you will have quick answers.
I'm still looking for a
I'm still looking for a version control system in Linux that doesn't scatter its directories all over your hard disk or require yelling 'I've got a new version' to the guy at the other end of the room.
How hard can it be to get this right?
bzr only puts a single .bzr
bzr only puts a single .bzr directory inside the root directory of whatever bzr project you are working with. (e.g. /project-1/.bzr OR /project-2/.bzr, never things like /project-2/images/.bzr as you would get with svn).
bzr also supports a central workflow so that each checkout is bound to a central version. Doing this means that when someone does a "bzr status" or "bzr commit" and their working tree is not up to date with the latest central repository's commit then the user will be displayed a "Working tree is out of date" message and in the case of a commit will be forced to update their working tree before committing. This should prevent having to yell across the room to say you have a new version. I believe you can also perform post commit hooks to automatically send emails when a new version is available.
Before distributed version control with bzr (and yes, even git or hg) I was always annoyed by the number of .svn directories I had kicking around in my working trees. The new generation of version control tools completely solves this annoyance.
I must vote for git & will
I must vote for git & will say to other Drupal users to vote for it.But you love Bazaar so we must love to know more from you about this one.walkie talkie review
I'd just like to say, after
I'd just like to say, after using SVN and BZR for a while. Bazaar bites. Sorry. It's just extremely frustrating to use. Sometimes it makes it nearly impossible for someone to get the latest code.
Say you change a file on your machine, but you don't want to commit it, you want to delete it and get the latest update. Good luck. Bazaar will make you work and do run arounds to get the latest code, because it tells the user "You have an up-to-date copy of revision 12" when its really revision 18 or so. Now you have to do a revert, then a merge, no that didnt work, still at r12... now give up and delete everything and get a new branch out. Dont even get me started on using a revert on a subdirectory - it will revert your ENTIRE tree and fry any other code changes. WTF, Bazaar? This program is definitely not easy to use, because there are way too many obscure commands needed to do simple things. There just is no bzr equivalent to "svn update", and that is a huge, major, glaring omission.
SVN wins the ease-of-use category, hands down.
Granted I havent used Bazaar on a very large project and I'm guessing that's where it's strength lies. Otherwise, I hate the stupid thing.
Here is a one type of
Here is a one type of metrics, namely how actively CVS, SVN, Git, Bzr and Mercurial are used by Debian GNU/Linux users:
70-646 exam I'd just like to
70-646 exam
I'd just like to say, after using SVN and BZR for a while. Bazaar bites. Sorry. It's just extremely frustrating to use. Sometimes it makes it nearly impossible for someone to get the latest code.