I'm a Subversion geek, why should I consider or not consider Mercurial or Git or any other DVCS?

283

240

I try to understand the benefits of distributed version control system (DVCS).

I found Subversion Re-education and this article by Martin Fowler very useful.

Mercurial and others DVCS promote a new way of working on code with changesets and local commits. It prevents from merging hell and other collaboration issues

We are not affected by this as I practice continuous integration and working alone in a private branch is not an option, unless we are experimenting. We use a branch for every major version, in which we fix bugs merged from the trunk.

Mercurial allows you to have lieutenants

I understand this can be useful for very large projects like Linux, but I don't see the value in small and highly collaborative teams (5 to 7 people).

Mercurial is faster, takes less disk space and full local copy allows faster logs & diffs operations.

I'm not concerned by this either, as I didn't notice speed or space problems with SVN even with very large projects I'm working on.

I'm seeking for your personal experiences and/or opinions from former SVN geeks. Especially regarding the changesets concept and overall performance boost you measured.

UPDATE (12th Jan): I'm now convinced that it worth a try.

UPDATE (12th Jun): I kissed Mercurial and I liked it. The taste of his cherry local commits. I kissed Mercurial just to try it. I hope my SVN Server don't mind it. It felt so wrong. It felt so right. Don't mean I'm in love tonight.

FINAL UPDATE (29th Jul): I had the privilege to review Eric Sink's next book called Version Control by Example. He finished to convince me. I'll go for Mercurial.

user2567

Posted 2011-01-09T13:51:19.637

Reputation:

+1 For getting me read about Mercurial, I am SVN guy too :) – M.Sameer – 2011-04-21T18:19:52.543

Any update on the results of trying DVCS? – alternative – 2011-06-01T21:29:43.253

I installed it today, and it works. It's all I can say for now. I'll provide you with more feedback after a week or two of usage. – None – 2011-06-08T14:36:58.720

Great. Remember the most important thing to actually try is to merge conflicts. – None – 2011-06-12T22:22:43.677

@Thorbjørn Ravn Andersen: this is not relevant to us. We rarely get conflicts for the following reasons: we apply principles like SOLID and continuous integration. In addition to that we promote pair programming when two developers must work on the same area of the code. – None – 2011-06-15T09:49:42.063

2@Pierre, that is because you only work on a single branch. When you reach maintenance mode and needing to port changes back and forth between branches this might change. – None – 2011-06-15T09:55:50.737

@Thorbjørn Ravn Andersen: It didn't so far. We are no different, we have release branches like most software project. I really think the difference is how we organize our work. – None – 2011-06-15T10:09:53.233

1You are working in a private branch if you ever check out a copy of the code to work on. Infact, this is the only way to use most version control systems. Subversion and other centralised VCS systems place a very significant restriction on this private branch - namely, you can have only one revision. (Some, like perforce, don't even let you safely merge without committing the current changes first in case the merge fails!) – Arafangion – 2011-08-09T23:18:39.210

3@Joonas No, one server can serve 2000 repositories and each programmer can check out the repository he needs. Its actually more efficient that way, anyways. – alternative – 2011-10-31T20:50:30.533

I've been using Mercurial and SVN concurrently on different projects and can honestly say that whatever problems DVCS is solving are problems I never have. With SVN, we have about a dozen team members who all commit multiple times a day and merges are needed maybe once a month and take 5 minutes. It's just inherent to the type of work we do. I understand conceptually why it is better, but no it won't give a benefit to everyone. Still, you should upgrade because why not. – jiggy – 2012-02-03T00:57:13.683

17-1 for the Katy Perry reference. ;) – Amadiere – 2012-03-05T12:04:36.993

1+1 for the Kate Perry reference :P – NlightNFotis – 2013-08-19T05:54:54.307

8I'm also very interested in this. Subversion fits the way I've been taught to think about version control (having come from CVS and the like). Nevertheless, while I've had to use Mercurial and Git to try some bug fixes for open source projects I haven't been converted yet. – Berin Loritsch – 2011-01-09T14:06:04.627

I personally see DVCS as an increase in steps therefore more likely to have problems, with one of the most basic things needed comit, you comit locally then have to push to a server(chances are someone will foget for a long time). where as CVCS you comit and everything is done, – Mumbles – 2011-01-09T14:54:42.947

28

+1 for the question. Nowadays it has become cargo cult that distributed is simply better, faster, simpler, more natural and trouble-free and 90 % shinier compared to centralized. Except that it necessarily isn't. They're different tools, and each may have advantages in some contexts and disadvantages in other contexts.

– Joonas Pulakka – 2011-01-09T16:29:56.117

2Branches are just not a first-class citizen in SVN-land the way they are in DVCSs. – Paul Nathan – 2011-01-09T17:02:16.280

2See edit to my answer. Regarding the cargo cult comment, don't let blind followers that are not able to defend DVCSs fool you. Subversion works, nobody argues that, DVCSs just let you work more naturally. See my edit to this second version of the question. – dukeofgaming – 2011-01-09T20:53:27.533

3@Joonas I think you should support your argument a little more before throwing words like "cargo cult" around. svn was my first version control system and I used it happily for years. I switched to git for the simple fact that it gave me a larger and more powerful set of tools for managing my source code---not because some mysterious stranger with a scraggly UNIX beard fed me kool-aid spiked with something suspicious. – Sharpie – 2011-01-09T22:26:22.417

17@Sharpie: Having used both svn, git and hg for years, I'm pretty well aware of their pros and cons. While git is certainly the most powerful of these, it's important to acknowledge that more powerful doesn't automatically imply better. Emacs is certainly more powerful than any javascript text editor running in web browser, but, strangely, I'm writing this comment into a javascript browser text editor right now! Simplicity, even stupidity, has value in many contexts. Using centralized svn and something like git-svn locally offers the best of both worlds. – Joonas Pulakka – 2011-01-10T07:35:11.590

2@Joonas: The distributed model puts at least one extra repository between my dumb mistakes and the rest of the team which is incredibly valuable no matter the project. Because of that, I can't understand the label "cargo cult" (going through the motions of something for no benefit). – Sharpie – 2011-01-10T19:00:30.717

9

@Sharpie: It's good for you that you like it. But one man's pro is another man's con. Some people consider the clarity of a single centralized repository with a single canonical trunk incredibly valuable. Here's a presentation on how Google keeps the source code of all its projects, over 2000, in a single code trunk containing hundreds of millions of code lines, with more than 5000 developers accessing the same repository. Would you rather prefer 5000 servers and the history of 2000 projects on everyone's desk?-)

– Joonas Pulakka – 2011-01-11T07:31:29.667

@Pierre, this isn't really an answer, but here are two links that have helped me in my slow progress to git-fu.

– Benjol – 2011-03-07T12:48:53.807

@Benjol: thanks Benjol, I really appreciate – None – 2011-03-07T13:06:22.227

Answers

310

Note: See "EDIT" for the answer to the current question

First of all, read Subversion Re-education by Joel Spolsky. I think most of your questions will be answered there.

Another recommendation, Linus Torvalds' talk on Git: http://www.youtube.com/watch?v=4XpnKHJAok8. This other one might also answer most of your questions, and it is quite an entertaining one.

BTW, something I find quite funny: even Brian Fitzpatrick & Ben Collins-Sussman, two of the original creators of subversion said in one google talk "sorry about that" referring to subversion being inferior to mercurial (and DVCSs in general).

Now, IMO and in general, team dynamics develop more naturally with any DVCS, and an outstanding benefit is that you can commit offline because it implies the following things:

  • You don't depend on a server and a connection, meaning faster times.
  • Not being slave to places where you can get internet access (or a VPN) just to be able to commit.
  • Everyone has a backup of everything (files, history), not just the server. Meaning anyone can become the server.
  • You can commit compulsively if you need to without messing others' code. Commits are local. You don't step on each other's toes while committing. You don't break other's builds or environments just by committing.
  • People without "commit access" can commit (because commiting in a DVCS does not imply uploading code), lowering barrier for contributions, you can decide to pull their changes or not as an integrator.
  • It can reinforce natural communication since a DVCS makes this essential... in subversion what you have instead are commit races, which force communication, but by obstructing your work.
  • Contributors can team up and handle their own merging, meaning less work for integrators in the end.
  • Contributors can have their own branches without affecting others' (but being able to share them if necessary).

About your points:

  • Merging hell doesn't exist in DVCSland; doesn't need to be handled. See next point.
  • In DVCSs, everyone represents a "branch", meaning there are merges everytime changes are pulled. Named branches are another thing.
  • You can keep using continuous integration if you want. Not necessary IMHO though, why add complexity?, just keep your testing as part of your culture/policy.
  • Mercurial is faster in some things, git is faster in other things. Not really up to DVCSs in general, but to their particular implementations AFAIK.
  • Everyone will always have the full project, not only you. The distributed thing has to do with that you can commit/update locally, sharing/taking-from outside your computer is called pushing/pulling.
  • Again, read Subversion Re-education. DVCSs are easier and more natural, but they are different, don't try to think that cvs/svn === base of all versioning.

I was contributing some documentation to the Joomla project to help preaching a migration to DVCSs, and here I made some diagrams to illustrate centralized vs distributed.

Centralized

alt text

Distributed in general practice

alt text

Distributed to the fullest

alt text

You see in the diagram there is still a "centralized repository", and this is one of centralized versioning fans favourite arguments: "you are still being centralized", and nope, you are not, since the "centralized" repository is just repository you all agree on (e.g. an official github repo), but this can change at any time you need.

Now, this is the typical workflow for open-source projects (e.g. a project with massive collaboration) using DVCSs:

alt text

Bitbucket.org is somewhat of a github equivalent for mercurial, know that they have unlimited private repositories with unlimited space, if your team is smaller than five you can use it for free.

The best way you can convince yourself of using a DVCS is trying out a DVCS, every experienced DVCS developer that has used svn/cvs will tell you that is worth it and that they don't know how they survived all their time without it.

EDIT: To answer your second edit I can just reiterate that with a DVCS you have a different workflow, I'd advise you not to look for reasons not to try it because of best practices, it feels like when people argue that OOP is not necessary because they can get around complex design patterns with what they always do with paradigm XYZ; you can benefit anyways.

Try it, you'll see how working in "a private branch" is actually a better option. One reason I can tell about why the last is true is because you lose the fear to commit, allowing you to commit at any time you see fit and work a more natural way.

Regarding "merging hell", you say "unless we are experimenting", I say "even if you are experimenting + maintaing + working in revamped v2.0 at the same time". As I was saying earlier, merging hell doesn't exist, because:

  • Everytime you commit you generate an unnamed branch, and everytime your changes meet other persons' changes, a natural merge occurs.
  • Because DVCSs gather more metadata for each commit, less conflicts occur during merging... so you could even call it an "intelligent merge".
  • When you do bump into merge conflicts, this is what you can use:

alt text

Also, project size doesn't matter, when I switched from subversion I actually was already seeing the benefits while working alone, everything just felt right. The changesets (not exactly a revision, but a specific set of changes for specific files you include a commit, isolated from the state of the codebase) let you visualize exactly what you meant by doing what you were doing to a specific group of files, not the whole codebase.

Regarding how changesets work and the performance boost. I'll try to illustrate it with an example I like to give: the mootools project switch from svn illustrated in their github network graph.

Before

alt text

After

alt text

What you are seeing is developers being able to focus on their own work while commiting, without the fear of breaking others' code, they worry about breaking others' code after pushing/pulling (DVCSs: first commit, then push/pull, then update) but since merging is smarter here, they often never do... even when there is a merge conflict (which is rare), you only spend 5 minutes or less fixing it.

My recommendation to you is to look for someone that knows how to use mercurial/git and to tell him/her to explain it to you hands-on. By spending about half an hour with some friends in the command line while using mercurial with our desktops and bitbucket accounts showing them how to merge, even fabricating conflicts for them to see how to fix in a ridiculous ammount of time, I was able to show them the true power of a DVCS.

Finally, I'd recommend you to use mercurial+bitbucket instead of git+github if you work with windows folks. Mercurial is also a tad more simple, but git is more powerfull for more complex repository management (e.g. git rebase).

Some additional recommended readings:

dukeofgaming

Posted 2011-01-09T13:51:19.637

Reputation: 10 182

1Good luck with SVN/CVS, person who downvoted =) – dukeofgaming – 2011-04-24T02:44:20.697

1Merging is still hard if lots of refectoring is being done that conflets with each other! DVCS just automate the process of doing the common simple merges – Ian – 2011-06-05T21:18:03.747

@Ian That is obvious, man, if you change the same line of course you are going to get a conflict. – dukeofgaming – 2011-06-05T21:30:37.130

4@Dukeofgaming, but the answer siad "use DVCS and get no more merge problems..." – Ian – 2011-06-05T22:06:59.720

2@Ian Yes no more merge problems. Not no more merge conflicts. – Craig Norton – 2011-10-27T16:32:40.633

1You still have to deal with merges if you want to get a single consistent master version composed out of conflicting commits by many people. What a DVCS does is avoid the (worst parts of the) problem of warring commits to a single branch: the mess is there, but you can tidy it up without disaster hitting. – Donal Fellows – 2012-05-03T10:05:47.850

I'd propose this article for the links. It describes a very common problem (tangled changesets for multiple things at once), and how using git (or another dvcs) can solve it where svn makes it difficult. (Disclose: It's written by one of the github staff). http://tomayko.com/writings/the-thing-about-git

– Daenyth – 2012-05-03T15:14:12.553

+1: amazing answer – haylem – 2012-11-13T18:13:05.490

+1 for excellent answer. – Muhammad Mahbubur Rahman – 2013-03-21T07:45:11.070

+1 for using Cacoo. – GuenSeven – 2015-02-06T13:14:04.037

18Great answer, but just one question for those of us in the same boat as OP: can you explain how merging hell does not exist? Does an integrator or a contributor not need to go through the same actions when their fork has become out of date? – NicoleC – 2011-01-09T15:36:38.497

17Good answer. Just a side note: while Spolsky may have some nice points, bear in mind that he is also trying to sell a product using those points as selling material, which makes them a bit biased. – Martin Wickman – 2011-01-09T16:06:28.170

5I read that re-education page, and didn't found it relevant for many reasons. I'll edit my question with my personal view on the subject. – None – 2011-01-09T16:24:47.520

15It's worth also pointing out that Git can act as a Subversion client, meaning that you don't need to convert everyone to Git all at once; a few team members can just use Git if they like, and their individual workflow improves (notably because merging is much easier). – greyfade – 2011-01-09T17:50:19.457

2Fantastic job on the diagrams. They themselves deserve a +1 :). – yasouser – 2011-01-09T20:13:22.530

1Renesis and Pierre 303, I just answered you in my latest edit . Thanks to others for the comments. – dukeofgaming – 2011-01-09T20:47:02.193

5Continuous integration is still an impediment as it works on a different level than the DVCS. You need it to run tests automatically at every checkin! – None – 2011-01-09T20:48:57.447

1@Renesis Sometime merge hell does exist---for a brief moment between when git merge tells you there are conflicts and git mergetool helps you resolve them using your favorite diff programs without breaking a sweat. – Sharpie – 2011-01-09T21:00:29.387

1@Sharpie Wouldn't really describe it as hell anymore =P – dukeofgaming – 2011-01-09T21:03:35.790

@dukeofgaming My point exactly :) – Sharpie – 2011-01-09T21:49:02.137

@Thor: could you elaborate a bit? – None – 2011-01-09T21:50:30.003

6@Pierre, DVCS's take care of merging the software changes from the individual programmers, but not on actually making the software compile or pass the existing unit tests. You still need other software to do this whenever the source change, and the best bet we have these days is using a CI-engine (and doing it properly) – None – 2011-01-09T21:58:58.447

@George Thanks, I corrected it – dukeofgaming – 2011-01-26T21:33:24.157

54

What you are saying is among other things that if you essentially stay on single branch, then you don't need distributed version control.

That is true, but isn't it a needlessly strong restriction to your way of working, and one that doesn't scale well to multiple locations in multiple timezones? Where should the central subversion server be located, and should everybody go home if that server for some reason is down?

DVCSes are to Subversion, what Bittorrent is to ftp

(technically, not legally). Perhaps if you think that over, you might understand why it is such a large leap forward?

For me, our switch to git, immediately resulted in

  • Our backups being easier to do (just "git remote update" and you're done)
  • Easier to commit small steps when working without access to the central repository. You just work, and synchronize when you come back to the network hosting the central repository.
  • Faster Hudson builds. Much, much faster to use git pull than updating.

So, consider why bittorrent is better than ftp, and reconsider your position :)

Note: It has been mentioned that there are use-cases where ftp is quicker and than bittorrent. This is true in the same way that the backup file your favorite editor maintains is quicker to use than a version control system.

user1249

Posted 2011-01-09T13:51:19.637

Reputation:

I'm almost decided to try it with a real project. – None – 2011-01-09T19:06:50.207

Good idea. Remember to go into it with the mindset of "I really LIKE this!" instead of "I don't want to DO this!". There is a lot to learn. If you choose git, github has a lot of good online help. If you choose hg, Joel has written some good online material. If you choose bzr, Canonical most likely has a lot of good online material. Others? – None – 2011-01-09T19:19:17.523

@Thorbjorn: Great comparison! I personally wouldn't use bittorrent to transfer files between people sitting in the same room. Ftp would be more useful for that. – Martin Wickman – 2011-01-09T21:06:54.890

16+1 for the great analogy – dukeofgaming – 2011-01-09T21:18:36.053

3Hmm that assumes that you think that bittorrent is better than FTP... – Murph – 2011-01-09T21:33:03.163

2

@Murph, I do, and so do Blizzard (who I believe we can agree on knows how to deal with massive online synchronization?). http://www.wowwiki.com/Blizzard_Downloader

– None – 2011-01-09T21:54:53.147

@Martin, the analogy is not perfect, but good enough for a 30-second eyeglaze :) – None – 2011-01-09T21:56:02.693

@Thorbjørn For Git, gitref.org is a great place to start with basic commit/push/pull usage. gitready.com has articles on other tools and workflows and progit.org is an entire book, freely available online, that can really help you achieve Git mastery.

– Sharpie – 2011-01-09T22:57:24.293

@Thorbjørn - ok, this is not the place, but the point is that for a specific purpose bittorrent may be better but I do upload as well as download. So its not as simple as saying one is better than the other without a lot of context. Which makes it a problematic analogy. – Murph – 2011-01-10T09:48:41.147

@Murph, I do not agree but feel free to come with a better analogy. – None – 2011-01-10T11:32:55.150

@Thorbjørn - I use FTP to update the files on my webserver. How do I do that with Bittorrent? Which makes it an apples and oranges comparison. I'm not disputing the benefits though I do wonder about the downsides. – Murph – 2011-01-10T12:26:27.470

2@Murph, you start a torrent server on the server and a torrent client on the client. Not hard. It should immediately buy you that only the files that has changed needs to be updated. ALso, have you considered what rsync instead of ftp might buy you for incremental updates? – None – 2011-01-10T14:18:43.783

@Thorbjørn - ooo lots of bad assumptions there (-: – Murph – 2011-01-10T16:52:59.287

@Murph, you lost me there. Care to elaborate? – None – 2011-01-10T23:36:32.897

@Thorbjørn - will go lurk on chat – Murph – 2011-01-11T09:30:55.733

@Thorbjørn Blizzard, and Valve too, they even hired Bram Cohen http://techreport.com/discussions.x/6278

– dukeofgaming – 2011-01-11T19:37:07.240

43

The killer feature of distributed version control systems is the distributed part. You don't checkout a "working copy" from the repository, you clone an entire copy of the repository. This is huge, as it provides powerful benefits:

  • You can enjoy the benefits of version control, even when you don't have internet access such as... This one is unfortunately overused and overhyped as a reason DVCS is awesome---it is just not a strong selling point as many of us find ourselves coding without internet access about as often as it starts raining frogs.

  • The real reason having a local repository is killer is that you have total control over your commit history before it gets pushed to the master repository.

Ever fixed a bug and ended up with something like:

r321 Fixed annoying bug.
r322 Argh, unexpected corner case to annoying bug in r321!
r323 Ok, really fixed corner case in r322
r324 Oops, forgot to remove some debugging code related to r321
...

And so on. History like that is messy---there was really only one fix, but now the implementation is spread between many commits that contain unwanted artifacts such as the addition and removal of debugging statements. With a system like SVN, the alternative is to not commit (!!!) until everything is working in order to keep the history clean. Even then, mistakes slip by and Murphy's Law is waiting to brutalize you when significant amounts of work are not protected by version control.

Having a local clone of the repository, that you own, fixes this as you can re-write history by continuously rolling the "fix it" and "oops" commits into the "bug fix" commit. At the end of the day, one clean commit gets sent to the master repository that looks like:

r321 Fixed annoying bug.

Which is the way it should be.

The ability to re-write history is even more powerful when combined with the branching model. A developer can do work that is entirely isolated within a branch and then when it's time to bring that branch into the trunk you have all sorts of interesting options:

  • Do a plain vanilla merge. Brings everything in warts and all.

  • Do a rebase. Allows you to sort through the branch history, re-arrange the order of commits, throw commits out, join commits together, re-write commit messages---even edit commits or add new ones! A distributed version control system has deep support for code review.

Once I learned how local repositories allowed me to edit my history for the sake of the sanity of my fellow programmers and my future self, I hung up SVN for good. My Subversion client is now git svn.

Allowing developers and managers to exercise editorial control over commit history results in better project history and having clean history to work with really helps my productivity as a programmer. If all this talk about "rewriting history" scares you, don't worry as that is what central, public or master repositories are for. History may (and should!) be re-written up to the point where someone brings it into a branch in a repository that other people are pulling from. At that point the history should be treated as though carved upon a stone tablet.

Sharpie

Posted 2011-01-09T13:51:19.637

Reputation: 882

1@PaulD.Waite: Mercurial comes with a standard extension for rebase — no much different from Git. For the full git rebase -i experience, you should see the histedit extension for Mercurial. – Martin Geisler – 2012-03-11T10:38:05.610

@Benjol: sure, that was my understanding too. – Paul D. Waite – 2012-03-11T12:40:40.493

@MartinGeisler: ah, cool, I’ll take a look at that. I’ve never actually used Git, but there are definitely times with Mercurial when I’ve made accidental or disorganised commits and would like to clean them up a bit. – Paul D. Waite – 2012-03-11T12:42:29.513

-1 Unfortunately. I frequently work in rural areas and am on the road a lot and find that doing commits locally is a pretty big deal for me. – Michael Durrant – 2012-05-03T17:16:36.710

@MichaelDurrant: I know what you mean. Those frogs get pretty annoying after a while. – naught101 – 2012-07-01T02:58:56.420

Having internet access doesn't necessarily mean you have access to your company's VCS server: hence hell when one of my former employers decided we should all work from home one day (we were using SVN) – Jeremy List – 2015-06-17T03:36:20.713

4Rewriting history: is that just a Git thing? Or is it easy in Mercurial too? (If it is, I really need to start doing it.) – Paul D. Waite – 2011-01-10T10:08:34.913

3One should be aware of the Linux Kernel discipline when doing this -- namely, never rebase (or rewrite history) a branch that you've published publically. If you have branches that are public for short-term use (for merging into branches that get thrown away frequently like linux-next, or for someone to review and then throw away their local copies) then you can rebase those branches -- but your other users should be clear that the convention for that branch is that it can be rebased and shouldn't be merged into any other peoples' long-term branches. – Ken Bloom – 2011-01-10T14:38:22.613

3you might very well have Internet access without having full internal network access. That frequently happens to me when travelling. – None – 2011-01-11T08:42:17.010

3Not requiring internet access is a very big deal, because that's where the speed of DVCS comes from. As soon as you have to send packets over a network, you are slowing the process down by an order of magnitude or so regardless of how good your connection is. – Adam Lassek – 2011-01-26T23:33:10.153

5@Paul, my understanding that in Mercurial it can be done, but it isn't the base functionality or philosophy. – Benjol – 2011-03-07T12:46:32.157

18

dukofgamings answer is probably about as good as it can get, but I want to approach this from a different direction.

Let us assume that what you say is absolutely true, and that by applying good practices you can avoid the problems that DVCS was designed to fix. Does this mean that a DVCS would offer you no advantage? People stink at following best practices. People are going to mess up. So why would you avoid the software that is designed to fix a set of problems, choosing instead to rely on people to do something that you can predict in advance they are not going to do?

philosodad

Posted 2011-01-09T13:51:19.637

Reputation: 1 635

2Actually I would propose this argument as against DCVS. My company recently switched to Mercurial from CVS. People are erasing other peoples changes during merges way more often when on CVS. – Juozas Kontvainis – 2012-02-16T10:38:58.480

@JuozasKontvainis: I don't know mercurial very well, but in git you can disallow pushes that include merges that don't have HEAD as a parent, which prevents users pushing changes that don't have the most recent changes from master included. I'm sure there's something similar in mercurial. – naught101 – 2012-07-01T03:48:04.033

@naught101: actually, my company has that setting enabled. What happens is that programmer commits his changes locally, then tries push. He gets a response from server that he needs merge before he can push. He gets updates from the server and tries to make a merge commit. At this point I don't know exactly how those persons made a merge commit but on several occasions that merge commit basically erased the changes they got from server. – Juozas Kontvainis – 2012-07-02T10:00:32.827

1It sounds like people pulled the changes, then actually deleted the changes they got from the server when merging (which is possible). Of course, the changeset from the server is still there, so you can reset the repository to the state it was in before their changes. – philosodad – 2012-07-03T17:02:32.873

1

actually, it sounds like this: http://randyfay.com/content/avoiding-git-disasters-gory-story nice, non-critical article about what can go wrong with a git repo if you don't know what you're doing.

– gbjbaanb – 2012-10-09T21:16:35.543

5+1 for "People stink at following best practices" – dukeofgaming – 2011-01-09T21:22:23.817

8

Yes, it hurts when you have to merge large commits in subversion. But this is also a great learning experience, making you do everything possible to avoid merging conflicts. In other words, you learn to check in often. Early integration is a very good thing for any co-located project. As long as everyone is doing that, using subversion shouldn't be much of a problem.

Git, for instance, was designed for distributed work and encourages people to work on their own projects and create own forks for an (eventual) merge later. It was not specifically designed for continuous integration in a "small and highly collaborative teams" which is what the OP is asking for. It is rather the opposite, come to think of it. You wont have any use for its fancy distributed features if all you're doing is sitting in the same room working together on the same code.

So for a co-located, CI-using team, I really don't think it matters much if you use a distributed system or not. It boils down to a matter of taste and experience.

Martin Wickman

Posted 2011-01-09T13:51:19.637

Reputation: 11 752

But is it really the point of your version control system to 'not be much of a problem'? I understand the point about best practices, but I don't understand why spending intellectual capital on following best practices is better than using a system designed with them in mind. – philosodad – 2011-01-09T19:32:05.200

2Git was designed for distributed work across the globe and encourages people to work on their own projects and create own forks. It was not specifically designed for continuous integration in "small and highly collaborative teams" which is what the OP is asking for. – Martin Wickman – 2011-01-09T20:14:02.997

I don't see how checking often helps with respect to conflicts... If two people edit the same piece of code, you'll get a conflict no matter what! – Xavier Nodet – 2011-01-09T20:22:04.100

3Guess what, you get smaller/easier conflicts to solve. But if two ppl are changing the same parts of the code, you have a planning problem in your team, and that cannot be solved by any VCS. Distributed or not. – Martin Wickman – 2011-01-09T20:29:31.400

Why would you want to invest time on something that is not a problem in reality anymore?, unless you are bored and/or masochistic that is. – dukeofgaming – 2011-01-09T21:27:25.917

Learning how to go through merging hell when merging hell is no longer a requirement for merging. – dukeofgaming – 2011-01-09T21:42:52.373

4The OP is in a co-located team using CI. This means they make many small check-ins often (several times a day). Given this, I see no reason why using a dvcs should give any particular advantage and I see no reason why any huge merges should occur and thus no merging hell. I wouldn't recommend svn for a distributed team though, but that is not the case here. – Martin Wickman – 2011-01-09T21:57:10.500

2@MartinWickman - Mercurial was designed to committing, branching, and merging fast and cheap. That sounds perfect for continuous integration. Personally, I think that having the ability for Alice to branch her changes and suggest that Bob pull them and merge his changes onto that branch to check for problems--all without touching the central server or pushing changes anywhere--sounds like a great way for small and highly collaborative teams to work. – philosodad – 2011-01-10T08:47:46.327

@Philosodad: Yes your right. I'm not saying git/mercurial are bad in way (quite the opposite) just that I think their strengths are more tailored to a distributed work environment. – Martin Wickman – 2011-01-10T12:37:45.823

2My $0.02. I've used Subversion, Mercurial, and Git now for various projects. Subversion really seems to be the best choice for a very tightly integrated group doing continuous integration. Mercurial is a better fit for groups that might only do one build a day with a lot more code changes each time (that would create merge issues in SVN). Git seems like the way to go for people that have teams that can go days/weeks without actually pushing code together to make a build. – Brian Knoblauch – 2011-01-10T13:24:01.153

@Brian: I'm not really sure what the difference is between Git and Mercurial (aside from different commands in the interface) -- could you tell me more about why Git is better for teams that go weeks without actually merging code, and Mercurial is better for teams that merge once a day? – Ken Bloom – 2011-01-10T14:41:35.780

@MartinWickman -- Fair enough. @BrianKnoblauch: I don't know SVN very well. What feature of SVN is either absent or inferior in Hg, such that Hg is less suitable for a tightly integrated group making several builds a day? – philosodad – 2011-01-10T15:40:57.307

@Brain: My point exactly. svn works great when you do many small check-ins and using CI. – Martin Wickman – 2011-01-10T17:00:55.853

@MartinWickman, @Brian: okay, I've worked in tiny two person teams doing many small commits and several pushes a day, sometimes working at the same desk. We were using Hg. This is a tightly integrated group using CI. What features of SVN would make it more suitable for that environment? I understand that SVN is useful in that environment, I don't understand how it is more useful. – philosodad – 2011-01-11T17:43:48.367

8

Because you should continuously challenge your own knowledge. You are fond of subversion, and I can understand because I used it for many years, and was very happy about it, but that doesn't mean that it is still the tool that would suit you best.

I believe that when I started using it, it was the best choice at the time. But other tools come up over time, and now I prefer git, even for my own spare time projects.

And subversion does have some shortcomings. E.g. if you rename a directory on disc, then it is not renamed in the repository. File move is not supported, making a file move a copy/delete operation, making merging changes when files have been moved/renamed difficult. And merge tracking is not really build into the system, rather implemented in the form of a workaround.

Git does solve these problems (including automatically detecting if a file has been moved, you don't even need to tell it that is a fact).

On the other hand git does not allow you to branch on individual directory levels like subversion does.

So my answer is, you should investigate alternatives, see if it fits your needs better than what you are familiar with, and then decide.

Pete

Posted 2011-01-09T13:51:19.637

Reputation: 6 236

git uses a certain heuristic to determine if a file has moved, its good but not perfect. – gbjbaanb – 2011-04-22T00:15:44.373

Agree with that, even if you hate the new tool that the damn kids use, I think its important to force yourself to at least try new things, especially if these things are making massive waves. – Tjaart – 2012-07-04T16:09:28.320

Very true, experimenting alternatives should be automatic. – None – 2011-01-22T11:53:18.687

7

With respect to performance, Git or any other DVCS has a big advantage over SVN when you have to switch from one branch to another, or to jump from one revision to another. As everything is stored locally, things are much quicker than for SVN.

This alone could make me switch!

Xavier Nodet

Posted 2011-01-09T13:51:19.637

Reputation: 2 184

Agree, git checkout is extremely fast. – None – 2011-01-09T20:51:35.587

+1 for pointing that out, jumping between branches/changesets is quite fast – dukeofgaming – 2011-01-09T21:25:07.353

3

Instead hanging onto the idea that "by applying best practices you don't need a DVCS", why not consider that the SVN workflow is one workflow, with one set of best-practices, and the GIT/Hg workflow is a different workflow, with a different set of best practices.

git bisect (and all of its implications on your main repository)

In Git, a very important principle is that you can find bugs using git bisect. To do this, you take the last version you ran that was known to work, and the first version you ran that was known to fail, and you perform (with Git's help) a binary search to figure out which commit caused the bug. To do this, your entire revision history has to be relatively free of other bugs that can interfere with your bug search (believe it or not, this actually works pretty well in practice, and Linux kernel developers do this all the time).

To achieve git bisect capability, you develop a new feature on its own feature branch, rebase it and clean up the history (so you don't have any known non-working revisions in your history -- just a bunch of changes that each get you partway to fixing the problem), and then when the feature is done, you merge it into the main branch with working history.

Also, to make this work, you have to have discipline about which version of the main branch you start your feature branch from. You can't just start from the current state of the master branch because that may have unrelated bugs -- so the advice in the kernel community is to start work from the latest stable version of the kernel (for big features), or to start work from the latest tagged release candidate.

You can also back up your intermediate progress by pushing the feature branch to a server in the meantime, and you can push the feature branch to a server to share it with someone else and elicit feedback, before the feature is complete, before you have to turn code into a permenant feature of the codebase that everybody* in your project has to deal with.

The gitworkflows man page is a good introduction to the workflows that Git is designed for. Also Why Git is Better than X discusses git workflows.

Large, distributed projects

Why do we need lieutenants in a highly collaborating team with good practices and good design habits?

Because in projects like Linux, there are so many people involved who are so geographically distributed that it's hard to be as highly collaborating as a small team that shares a conference room. (I suspect that for developing a large product like Microsoft Windows that even if people are all located in the same building, the team is just too large to maintain the level of collaboration that makes a centralized VCS work without lieutanants.)

Ken Bloom

Posted 2011-01-09T13:51:19.637

Reputation: 2 059

I don't get your first point. Do you have some references? Regarding the last one, I would divide the project into separate components instead. I never worked on a such large projet, the maximum number of developer I got on the same project is two dozens. – None – 2011-01-09T17:50:00.633

@Pierre. That's certainly reasonable to divide the project into separate components. Since Linux is a monolithic kernel, that means (essentially) that all the device drivers have to be developed in the same repository, even though each is essentially a separate project. At the same time, they want the agility for their more experienced architects to make wide-ranging changes that touch all of these drivers, so breaking them up into different repositories will be a pain. So git (and lieutenants) suit them well for managing these different concerns. – Ken Bloom – 2011-01-09T17:55:37.977

You might also be interested in reading what Martin Fowler has to say about SVN versus Git and Mercurial workflows. http://martinfowler.com/bliki/VersionControlTools.html

– Ken Bloom – 2011-01-09T17:56:11.753

@Ken: yes I read that article and updated my question. I think SVN and Mercurial/Git are two different paradigm. Just like some people buy Volvo instead of Ford – None – 2011-01-09T18:04:46.430

2I do bisections on SVN regularly to find bugs. The only difference with Git is that it's not all automatic. But this alone would not be enough for us to switch. – Xavier Nodet – 2011-01-09T20:18:08.330

@Pierre303, your car analogy is very bad :-S – None – 2011-01-09T20:51:01.080

Ken: could you post it as an answer ? – None – 2011-01-09T21:51:32.233

@Pierre: which comment should I post as an answer? – Ken Bloom – 2011-01-09T23:53:37.590

@Ken: Martin Fowler opinion – None – 2011-01-10T09:37:24.480

1The relevance of git bisect for small teams is almost nil. I get it for the kernel where hundreds of changes from different people are being merged in at once and breaking things, but when you have a team of 5, you can usually eliminate all but 2-3 potential culprit patches with a quick look at the log. – blucz – 2011-01-26T18:19:54.037

2

Why not use them in tandem? On my current project we are forced to use CVS. However, we also keep local git repositories in order to do feature development. This is the best of both worlds imo because you can try various solutions and keep versions of what you're working on, on your own machine. This allows you to rollback to previous versions of your feature or try several approaches without getting into issues when you mess up your code. Having a central repository then gives you the benefits of having a centralized repository.

Vadim

Posted 2011-01-09T13:51:19.637

Reputation: 644

But you can just set up a central repository with a DVCS (and you can control permissions just as tightly as with a CVCS. So what are the benefits? – naught101 – 2012-07-01T03:04:12.030

True, but central git repositories may be difficult to set up if you are in a Windows environment. I guess that's pretty much the only one I could think of. We were forced to use CVS at the corporate level, so we didn't really have much of a choice. – Vadim – 2012-07-05T18:45:45.580

1

I have no personal experience with DVCS, but from what I gather from the answers here and some linked documents, the most fundamental difference between DVCS and CVCS is the used working model

DVCS

The working model of DVCS is that you are doing isolated development. You are developing your new feature/bugfix in isolation from all other changes until the moment you decide to release it to the rest of the team. Until that time, you can do whatever check-ins you like, because nobody else is going to be bothered with it.

CVCS

The working model of CVCS (in particular Subversion) is that you are doing collaborative development. You are developing your new feature/bugfix in direct collaboration with all the other team members and all changes are immediately available to all.

Other differences

Other differences between svn and git/hg, such as revisions vs changesets are incidental. It is very well possible to create a DVCS based on revisions (as Subversion has them) or a CVCS based on changesets (as Git/Mercurial have them).

I am not going to recommend any particular tool, because it mostly depends on the working model that you (and your team) are most comfortable with.
Personally, I have no problems with working with a CVCS.

  • I have no fear of checking in stuff, as I have no problems getting it into a incomplete, but compilable state.
  • When I experienced merge-hell, it was in situations where it would have occurred in both svn and git/hg. For example, V2 of some software was being maintained by a different team, using a different VCS, while we were developing V3. Occasionally, bugfixes would have to be imported from the V2 VCS to the V3 VCS, which basically meant doing a very large check-in on the V3 VCS (with all bugfixes in a single changeset). I know it was not ideal, but it was a management decision to use different VCS systems.

Bart van Ingen Schenau

Posted 2011-01-09T13:51:19.637

Reputation: 37 033

I don't think that isolated development is actually the working model of DVCS. One important feature of a DVCS is that other members of the team can pull your local changes or clone your local repository. You commit when you like, your changes are always available, and your bugs can't cause mass havoc. – philosodad – 2011-01-10T15:55:43.270

@philosodad: If others pull code from my repository without knowing the state of that code, it can still cause havoc. The only difference is in whose responsibility it is. And my code is not always available. That still depends on if my systems are configured for outside access. – Bart van Ingen Schenau – 2011-01-11T10:59:24.947

If people pull code from your repository and merge it with their own, they can roll back, independently, without any mass issues. Second, sure, if you make a decision to refuse access to your codebase and cripple a major feature of the system, you can force isolation on yourself. That's a lot different from a system being modeled for isolated development. DVCS is not. Your understanding of the working model of DVCS is simply wrong. – philosodad – 2011-01-11T17:39:24.053

1@philosodad: I think I am starting to understand it better and better: Everyone can get your mess, same as in a CVCS, but it is no longer your fault, because you did not push it on them. :-) – Bart van Ingen Schenau – 2011-01-12T15:07:55.260

Well... sort of. But typically, Alice would clone or branch first and then merge your changes, which makes it easier to just pretend she never saw your buggy code in the first place! – philosodad – 2011-01-12T15:37:05.043

Asked: 2011-01-09T13:51:19.637

Viewed: 33 674 times

Active: 2012-12-19T08:21:43.187