Current Articles | RSS Feed RSS Feed

Why Subversion does not suck

Posted by Andy Singleton on Thu, Dec 11, 2008
The Subversion sucks meme, which has become very popular in the blogosphere (starting with Linus Torvalds and continuing here here and finally here for example) asserts that Subversion is obsolete and will fade away because distributed version control systems like git (mostly git), Mercurial and Bazaar offer a better and more flexible workflow.  If we imagine a world without Subversion and other centralized version control systems, it's easy to see why Subversion does not suck, is not fading away, and in fact, has a rapidly growing user base.

As a disclaimer, I admit that Assembla has moved to git for its internal product development, and we are actively supporting both git and Mercurial repositories, as well as supporting the great open source workflow on github with our Assembla Tickets for Github package.  I can see the limitations of Subversion in absorbing code from a diverse group of contributors.  In the central repository, they can break the build, or force you to engage in a high-stakes merge that affects everyone.  Even with those limitations, we use Subversion for our work with clients.

To see the value of Subversion, imagine a world where git is the only option.  Codehounds use it to manage their personal code base, and to write code for bigger projects and push it to the team leads.  Team leads use that distinctive distributed VCS workflow to pull the changes they want and assemble the daily and milestones releases.  In this world, new programmers go to class to learn several dozen git operations, learn to navigate the maze of branches, and become “git certified”.  But, this growth industry of training doesn't reach designers, clients, and other non-programmers, because this stuff is just too complicated for them.

Imagine that in this world someone announces a radically simplified VCS option called centralized Subversion.  With Subversion, everyone is working on the same thing.  It unifies a team.  And, it's radical because it's really easy to use.  You get a graphical client with four point-and-click operations – checkout, update, revert, and commit.  Even designers can use it.  Even clients can use it.  People rave about its usability,  and its mind-melding social structure.

In this world, people might start saying that git sucks, that it's obsolete, that it will fade away.  Of course, they would be wrong, just carried away.

Get your free Subversion repository with an issue tracker and all the worflows you want with Assembla Renzoku

Tags: , , ,


Just give the client the equivalents of those 4 simple operations. Set the source of their repo to a single master copy and magically 'git push origin master' is almost exactly the same as 'svn ci'. 
The real benefit of git/etc is that not only does it enable new, more efficient workflows but also lets you exactly mimic existing workflows. 
In short, you can do what subversion does with git, but you can't do what git does with subversion.

posted @ Thursday, December 11, 2008 11:47 AM by dude

Quite. In a world without Subversion, Subversion would be built out of Git. In a world without Git, Monotone, Darcs etc. ... well that's where we were 5 years ago, and it sucked.

posted @ Thursday, December 11, 2008 12:03 PM by Tom

The problem I have with this line of reasoning is that it assumes that DVCS must be more complicated than its centralized sibling. 
This is just not true. 
Let's compare and contrast workflow of Subversion and Mercurial (which I know better than Git). We'll even assume that a repository has already been created for you. 
Setting up your local copy of the repository? svn checkout url or hg clone url
Updating? svn update or hg pull 
Committing work? svn commit (unless you're off-line, then you just stop) or hg commit; hg push (unless you're off-line, then you wait and batch your commits). 
Changes to the filesystem? svn {add,delete,copy,move} == hg {add,remove,copy,rename}. 
Want to see what has changed? svn/hg {status,diff}. 
Ok, let's get complicated. You want to set up a new repository for your company. Subversion: svnadmin create /usr/local/svn/newrepos && svn import mytree file:///usr/local/svn/newrepos/some/project (straight out of the docs: While you're doing that, read over and to make sure you can keep it working. 
The same with Mercurial? Get into the code directory you want to work with, and hg init && hg addremove. This will put all these files in the repository, so you could instead hg add those you're interested in, but the former command would be Subversion's create/import pair. Share with ssh, or put it on a shared directory, or whatever. You can even get the nice http interface by running "hg serve" (a good way to start, and you can ramp up later if you want). 
Oh, and if it's the graphical interface you want, Tortoise makes the same thing for Mercurial, as well: (See also for even more cool GUIs.) 
As I said, I'm more familiar with Mercurial, so I'm not sure if all this holds for Git, but from what I've heard, it does. What about documentation? The Mercurial book ( is just as good as the Subversion one, IMHO. 
tldr? Mercurial is as simple to learn (if not simpler) than Subversion, and is easier to play around with (hg init > svnadmin create).

posted @ Thursday, December 11, 2008 12:12 PM by Adam Blinkinsop

@Tom, git getting stuck.. lol. maybe you forget that subversion gets its bdb 'stuck'.. which imo is far worse. 
subversion isnt bad perse, it just has more, bigger, uglier warts than git does. 
how many years did it take for them to implement proper branch tracking and merging? obviously such fundamentals are not very high priority to the svn team. 

posted @ Thursday, December 11, 2008 12:23 PM by Winston Churchill

Right on, although most of the critical commenters here are missing the point. git was designed first and foremost for the linux kernel by linus torvalds himself, who is interested in programming for its own sake, in his words, he does it "just for fun." 
Yeah, for a lot of software projects nowadays, many developers understand at least the concept of git, using git makes a lot more sense than something like subversion, once you get your brain wrapped around it, and certainly at times going "back" to subversion may seem like drudgery. But the whole point here is that in some cases, where users are non-programmers, they have neither the desire, ability, nor time to learn or trip over git's umpteen commands and vocabulary (plumbing and porcelain). And they want a GUI: right now github has a open request out for a tortoisegit implementation for just this reason - it would make using git easier. 
I think this whole subversion sucks meme is just a byproduct of people's excitement with DVCS. The reason linus torvalds dislikes subversion is that it sucks for his workflow of developing the linux kernel, where he merges changes across 20,000 files several times a day. 
It's like the math nerd trying to tell an english major about some amazing things in his curriculum: the english major just doesn't get it or care, and should stick with subversion.

posted @ Thursday, December 11, 2008 12:47 PM by Ben

For the average corporate developer SVN is a definitely a good thing. It gives corporations an easy migration path away from the CVS dinosaur to SVN, which is easier, faster, and more feature rich. Corporations are willing to make this move because SVN aimed to be a better CVS. People who've worked with CVS for years can switch to SVN with only a few conceptual differences to understand.  
Obviously, there's a lot of projects that need the newer DVCS's, but a vast amount of corporate software development doesn't. For a lot of typical corporate development SVN is a wonderful improvement over CVS. 

posted @ Thursday, December 11, 2008 12:50 PM by devdanke

you hit the nail on the head. git needs a decent gui for windows and telling people to run cygwin and git-gui is not it. once tortise or someone out there, gets a gui that integrates with windows explorer and eclipse, you'll see git overtake svn. for now i just can't bother learning 50 different commands to do something when i can do it with one click of the mouse. there was a time in my life when i would have sat down and learned git, but now i'm too old and just want to get the work done that i need to do and then get drunk :)

posted @ Thursday, December 11, 2008 1:28 PM by tony petruzzi

some random thoughts: 
i'm wondering why you're comparing subversion and git on a target audience that wouldn't understand the latter? 
git will not out-svn svn.. and of course svn will not fade.. and that's b/c we have designers, clients, and other non-programmers -- i think most people knows that.. 
most of the "subversion sucks meme" is about svn being sucky compared to git.. so why not answer that one instead of an entirely different post (you're not trying to defunct what they claim, are you?) -- although i think they should title their blog posts to "subversion sucks compared to git" or someth with a witty title..

posted @ Thursday, December 11, 2008 1:45 PM by popol

You may want to take a look at my blog post from last April: 
I think we're saying much the same thing. :-)

posted @ Thursday, December 11, 2008 2:55 PM by Ben Collins-Sussman

Andy-- In the hypothetical world you describe, when subversion came out, people would say, "gah, this sucks compared to Dropbox." "Oh yeah, we just use Basecamp for this." There are other even easier to use options for dealing with non-technical people that need access to some type of VCS. Subversion may be stuck in the crappy valley.

posted @ Thursday, December 11, 2008 3:49 PM by JB

"how many years did it take for them to implement proper branch tracking and merging?" 
@Winston Churchill -- it's not finished yet :) See Bug 3128 and this discussion topic. Perforce, ClearCase and possibly AccurRev are the only centralized systems I know of that handle these situations. I'd be curious to know how git, darcs, mercurial et al. handle it. -Tim 

posted @ Thursday, December 11, 2008 3:59 PM by Tim Miller

Maybe it's the mathematician in me, Ben, but I don't understand. Your claim is SVN is easier to learn compared with git's rich vocabulary. Well, sure; the sticking point for me is: because git has more functionality, do you HAVE to learn it? Why get a set of tools with all those options when a hammer is so easy to use and is so flexible? It's easy to teach a CEO how to use a hammer. Yeah, your whole team is used to SVN commands. But, really, you can use git just like you use SVN; if you're competent, you just write some scripts which map svn update or whatever to the git equivalent. There. No learning curve, no scaring the CEO with options, power or flexibility. As far as the Windows users who need a point-and-click... one will come, I'm sure. Maybe it'll be as useful as SmartSVN is for my company. I have nothing but time to wait for it to do the simplest operations to complete and really enjoy having to delete a repo and re-fetch it because SmartSVN is just buggy. Oh, and Ben? Linus may do it "just for fun" -- but you're really going to use that as a justification to avoid git? I suppose you don't think Linux is a serious OS because Linus did it "just for fun"?

posted @ Thursday, December 11, 2008 4:51 PM by Jeremy

SVN doesn't suck because other VCS's are much better, but because it is simply broken

posted @ Thursday, December 11, 2008 4:56 PM by alberto

I've used all of the popular VCS out there, and I must say that I find Mercurial to be the easiest and most intuitive of the bunch. 
I really DON'T like SVN's idea of being so generic that you must make what are essentially directory copies in order to make tags and branches. Why not just make those concepts central to the VCS itself? I can't think of a single project that doesn't at least tag, so why make the process so complicated? 

posted @ Thursday, December 11, 2008 5:43 PM by Wolter

@Tim Miller 
I believe the default merge strategy for git (recursive) can detect and handle merges involving renames. 

posted @ Thursday, December 11, 2008 6:24 PM by bazfoo

Subversion does not have rename.

posted @ Thursday, December 11, 2008 6:37 PM by Cristian

svn was an excellent improvement over cvs. For a productive developer, however, svn does suck vs. git. 
The article is right about non-developers though. As someone who works with a lot of designers (most apps I work on are design-driven as my clients tend to be ad agencies & design firms) I don't see git happening in that world.  
@Adam Blinkinsop: it is not that the commands are more difficult or that there are more of them. It is that distributed version control is not easy conceptually for most people who are not developer-types. Svn is difficult enough to explain and sell. It usually only gets adopted by the non-developers after an expensive mistake, and even then requires constant cajoling & explanation and oversight. 
For developers, though...switching to git is like going jogging one day and discovering that 50kg weight you never realized you were wearing is gone.

posted @ Thursday, December 11, 2008 6:46 PM by lastobelus

I find it interesting that everybody thinks that there should be only one tool for different situations. 
I agree that git/mecurial/what ever is a better solution for open source projects with a distributed development team. However, most software is developed in a corporate environment. In that environment, it is preferable to have a centralized system. It ensures that everybody is on the same page. 
Just my opinion... 
on a side note... 
> Subversion does not have rename.  
rename is an alias for move. It will rename a file in the same directory, or move it to another directory. 

posted @ Thursday, December 11, 2008 6:49 PM by David

@lastobelus -- but you can use DVCS tools just like centralized tools. There's no difference until you need it. How would you sell Subversion differently than Mercurial? On features? Mercurial can do all that Subversion can do and more. On simplicity? Leave out the features they don't need quite yet. 
I just don't see why Subversion would be better for anyone, given that it's a proper subset of most (if not all) DVCS tools, including GUI and feature support.

posted @ Thursday, December 11, 2008 6:50 PM by Adam Blinkinsop

Ugh. These "my $soandso is better than your $soandso" posts are tiresome, other than for exposing flaws in one or the other system. 
I would hope that was the goal of this post, but I'm not certain it is.

posted @ Thursday, December 11, 2008 7:27 PM by erikh

Before everyone starts beating on subversion for what it doesn't do they should remember what it was built for in the first place. I found this a nice read from the official blog

posted @ Thursday, December 11, 2008 8:01 PM by Peer Allan

The big problem with most of the DVCSs out there (all of them) is that they don't handle partial checkouts well. If you have two projects that share a library, for example, that's easy with something like Subversion, you have a repository that contains projA, projB, and libZ, and just check out projA and libZ or projB and libZ. Easy. People working on either project can work on changes to libZ, possibly in branches and merge them later. 
In the DVCS world, you have to grab the combined repository, even when you don't need projA or projB (which might be massive), or you have to have two repositories projA-and-libZ and projB-and-libY, where libY actually equals libZ, but the DVCS system doesn't know that, and so can't track file identity properly. 
I keep hoping people in the DVCS world will understand this problem, but they all seem to imagine that no one would ever want to do this. And apparently, for a lot of open source projects, they're right, because there isn't much sharing going on. 

posted @ Thursday, December 11, 2008 9:07 PM by iMneme

> In this world, new programmers go to class to learn several dozen git operations, learn to navigate the maze of branches, and become “git certified”.  
You are smoking crack. 

posted @ Thursday, December 11, 2008 9:26 PM by Captain USA

Ah, the beauty of enlightenment. The perception is one way and yes we do see you! As a distant thought perhaps and not that often, but we do remember being in your place. 
Another way to look at the situation: what would eventually displace git? There are probably very few people that have a vision for a way to obsolete it. Since society as a whole has yet to catch up, the pressure to do so isn't there yet. 

posted @ Thursday, December 11, 2008 11:22 PM by Lenny

All this talk of building an svn-like wrapper interface to git is pretty bogus at this point in time, given that git lacks basic support for tracking filesystem changes. Did you know git refuses on principle to track empty directories, as well as all filesystem permissions other than the executable bit?

posted @ Thursday, December 11, 2008 11:46 PM by Alan

The culmination of SVN's transactional tree approach is probably something like ZFS, exported as samba shares to normal people so they can carry on with their vastly inferior, filesystem-centric workflows.

posted @ Thursday, December 11, 2008 11:57 PM by Alan

Alberto pretty much sums it up. 
If the thesis of the article is that git is too complicated to use for some people who might be able to use subversion, then I agree. 
But the truth is that subversion would be better if the team threw all the code away and rebuilt it using git primitives. I'm not sure where you would draw the line feature-wise, but it's easy to imagine any balance of power vs simplicity. You could probably do simpler and more powerful pretty easily as well. 
If subversion didn't have "branching" I think this article would make more sense. But the fact is that branching is mostly useless without merging. And someone who does not have the capacity to learn git is not going to sooner or later find themselves painted into a very difficult corner with subversion merges.

posted @ Friday, December 12, 2008 12:54 AM by Gabe da Silveira

>> Subversion does not have rename
> rename is an alias for move. It will rename a file in the same directory, or move it to another directory.  
That operation is actually delete + add.

posted @ Friday, December 12, 2008 2:37 AM by Cristian

Actually, 'svn mv' is exactly identical to running 'svn cp; svn rm'. It's a copy, not an add, so that history is tracked going backwards. 

posted @ Friday, December 12, 2008 9:28 AM by Ben Collins-Sussman

So the only thing the article is saying is that there aren't any decent GUI's for non-developer folks yet? Well, that doesn't sound like something that can't be fixed. Surely that's not a fundamental flaw that makes it impossible to overtake SVN? 
GUI's are being worked on. Take a look at GitX for example.

posted @ Friday, December 12, 2008 4:15 PM by Pieter 

posted @ Sunday, December 14, 2008 8:42 PM by billy

"But, this growth industry of training doesn't reach designers, clients, and other non-programmers, because this stuff is just too complicated for them." 
Oh, come on. I like some aspects of subversion (e.g. eol handling), and am using it for a current project (with your site). But "Git is just so darn hard" is implausible. It can make simple things simple, and as others have noted there is already a TortoiseGit client in development (not that such GUIs always make things easier, they don't). 
"Did you know git refuses on principle to track empty directories, as well as all filesystem permissions other than the executable bit? " 
hg doesn't allow empty directories either (oh, I forgot that's part of the marauding DVCS horde too). So what? It's not a backup system, nor is it meant to "track filesystem changes" it's a version control system. Sources (as opposed to binaries) do not usually need empty directories, or permissions. Those are handled at installation time.

posted @ Tuesday, March 31, 2009 4:01 PM by Matthew Flaschen

"Sources (as opposed to binaries) do not usually need empty directories, or permissions." 
Populated directories aren't really "source" either, but git tracks them anyway. It also tracks renames and the executable bit, so defending git's purity as a content tracker ("it's not a backup system") seems to be all about drawing a dogmatic line in the sand. 
Want to version your home directory with git? Sorry, you can't store the 0700 permissions on ~/.ssh, you'll have to fix up every checkout. Want to version a legacy project that assumes an empty directory for output? Sorry, you need to go change that. 
I fail to see why the world is better off with a git that doesn't track filesystem permissions and empty directories. And I don't see what's so heretical or hard about capturing permissions as content (ala tar) and just tracking that.

posted @ Wednesday, April 01, 2009 4:18 PM by Alan

Brit slang a contemptible person [from get (in the sense: to beget, hence a bastard, fool)] 
Collins Essential English Dictionary 2nd Edition 2006 © HarperCollins Publishers 2004, 2006

posted @ Tuesday, April 14, 2009 9:44 AM by Git

i can't believe that anybody in the 21th century want use svn. you have to think about so many ugly svn peculiarities. i can't work with it, i don't want it!!!!!

posted @ Saturday, May 16, 2009 5:14 AM by svn sucks absolutly!!!!

I recently used SVN over Git for the reason given by iMneme: partial checkouts. 
I was using SilverStripe and wanted only a single repository but within it I had several modules that I wanted to be able to check out into a ready made Silverstripe installation so that I could test it. 
This is not really doable with Git since I didn't want to have to have the Silverstripe core files intermingled with my Git tracked files and I didn't want to have to copy the modules over to some test folder every time I made a change. 
So I went with SVN. It is not perfect and I really do like Git, especially for forking projects and open source development with lots of contributors, but SVN does the job sometimes and so it will continue to be used for some time.

posted @ Thursday, June 18, 2009 1:26 PM by Pete BD

Folks, the REAL reason why permissions aren't tracked is because there exists no portable, OS-independent way to do it. Although Windows allegedly supports POSIX API calls, you still need a POSIX environment to really make use of them. Hence, mingw and cygwin. 
As far as empty directories are concerned, this is a space optimization, intended to keep server-side storage requirements to a minimum. The idea being, why store something that's empty? Of course, in today's world, it doesn't make sense, especially now that folks are using SOURCE control systems for CONFIGURATION management systems. (Notice the difference.) Hint: Neither SVN nor Git are configuration management systems. Get used to it! 

posted @ Wednesday, July 01, 2009 12:27 PM by Samuel

Oh, one more thing -- the company I'm working for is just one more company dropping Subversion in favor of Git. This includes the folks who aren't ultri-genii.

posted @ Wednesday, July 01, 2009 12:37 PM by Samuel

Using a tool which is able to manage the creation/deletion of placeholder files for empty directories automatically helps to overcome the issue of not being able to add empty folders to a git / mercurial repository. See the open source tool MarkEmptyDirs.

posted @ Thursday, August 27, 2009 1:55 PM by Jonny Dee

For all but the largest project, I just plain prefer subversion to git or mercurial. While it's easy to extol the virtues of a distributed version control system, it's hard to find a place these features are used. Most mercurial teams still have one, primary repository with repository-side branches and a traditional clone/change/commit/push development cycle. 
The way subversion lays out branches, as being copied of files, is just plain simpler. Sure, it needs better merging/branching tools and some improvements on the efficiency of revisions, but those are small improvements that could be made to an otherwise incredibly useful piece of software. 
Git/mercurial require formal, disciplined procedures to even work consistently. There are too many ways to do the same thing (like branching, or sending a changeset), and as a software engineer with ten years experience, I'll be the first to say that I find hg's manpage hopelessly complicated. (Two heads, one branch, really?) 
I think you'd have a hard time making a serious argument that a distributed version control system is useful for anything but the largest projects, and even then, it wouldn't be useful if some modest improvements were made to subversion.

posted @ Monday, February 08, 2010 5:44 PM by Ken

I have to say I am surprised that so many people seem to think that distributed version control is somehow easy/straightforward. I think the ease of subversion justifies some of its (well-known and well-noted above) shortcomings and thus agree with Andy on that front. Simplicity sometimes is its own reward. 
I think the article omits a major "lack of win" with the distributed nature of git and its brothers: continuous integration servers. When you are doing continuous integration with something like bamboo or hudson, you often have a culture that is one of frequent checkins and many tests. This leverages the CI system to the maximal extent and insures that everybody on the team stays "together." This is even true when you have a few, main branches (say major product versions) and you want to make sure the branches are always in working order.... in this world, the ability to do all the things that a distributed system offers are of far less value since--at the end of the day--there is only the one "true" version that is the one built by the CI server.  
I'm not saying that distributed systems like Git/mercurial/bazaar are not more powerful--they most certainly are. However, this power/flexibility is of far less *practical value* when all team members are doing "small integrations" all the time and there are one or a few "key builds" that all agree are to be kept in alignment with the entire team. If Joe can go off "on his own" using feature X of Git but is expected to merge his changes in before lunch, does it really help?

posted @ Wednesday, February 17, 2010 12:54 PM by Ian Smith

What's most telling is that those people that do use Git for non-trivial projects invariably use it as if it were Subversion, i.e. as a centralized, non-distributed VCS: that's simply the only way a real software project can progress without the developers shooting each other in the face.

posted @ Friday, February 19, 2010 6:57 AM by Simon

I went from using CVS for about 20 years to Mercurial for the last year and a half and I love Mercurial.  
There are 10 people in my team. We all commit back to a single, central repository. There has never been any issues.  
I had a chance to choose between Subversion, Git, Bazaar and Mercurial. I am so glad we didn't go with Subversion. 
Mercurial fits us perfectly. We have an office and a lab in a separate building. I run the Mercurial web server on my office machine. When I go to the lab I pull from my office machine because that is my development code. When I'm done in the lab, I push my changes back to my office repository. From my office repository I push to the main repository. 
I particularly like working with Mercurial's patch feature called Mercurial Queues.  
I have found Mercurial to be flexible and easy to use.

posted @ Friday, February 19, 2010 12:36 PM by Greg Strockbine

Thanks, Greg, you've kindly helped to prove my point. You're another shop using a supposedly-distributed VCS *exactly* as if it were Subversion. What does this buy you other than a system that'll be unfamiliar to any developer joining the team, and poor tool support?

posted @ Tuesday, February 23, 2010 10:23 AM by Simon

I kind of lost track of Subversion. So what you are telling me is that when I pull from the main Subversion repository, I get a complete repository on my local machine and I can edit and commit to this local repository and then when I feel confident about my changes I can push them to the main repository? Plus I can clone my local Subversion repository to my laptop? 
If so then Subversion is also a DVCS and can be considered along with Bazaar, Git and Mercurial. 
Also, everyone at my company was brand new to Mercurial, yet were able to pick it up quickly and are quite happy with it. So ease of use is not unique to Subversion, if that is what you are implying.  
Tool support is pretty darn good for Mercurial. 
TortoiseHg is excellent, it even supports Mercurial Queues. The Netbeans IDE has an excellent interface to Mercurial. And we found a plugin for Visual Studio that links into TortoiseHg. 
No one at my company has complained about poor support. 
Also, I apologize for any snideness on my part, I don't want to start a flame war. :-)

posted @ Tuesday, February 23, 2010 11:51 AM by Greg Strockbine

It's funny how almost nobody said that Subversion sucked when Git etc. weren't there yet ;)

posted @ Thursday, March 18, 2010 12:04 PM by Franz

until git understands SVN autoprops i'm not touching it with a ten foot pole.

posted @ Wednesday, April 07, 2010 3:01 AM by sajaki

Sources (as opposed to binaries) do not usually need empty directories, or permissions. Those are handled at installation time.  
I believe you are mistaken. CVS doesn't correctly handle empty directories either, and that is why my 20 year old source tree has so many files named ".cvsignore". Each one prevents some directory from being empty. 
I guess it is good that we didn't delete them when we switched to subversion, because we might need them if we ever switch to git. 
The big problem with most of the DVCSs out there (all of them) is that they don't handle partial checkouts well. 
This is a deadly flaw to me, since I routinely work with a tiny subset of a repository that takes 45 minutes to do a full checkout. (It averages about 0.6 msec per file.) 
the sticking point for me is: because git has more functionality, do you HAVE to learn it?  
Yes, do. I've looked at documentation for hg and git, and they authors are obviously in love with the distributedness of it all. 
You can give all the examples you want about how to make hg/git work just like subversion, but if you want to advocate for the DVCS, write a section for their documentation titled "I don't want to understand all this, how do I pretend it is subversion?" 
Without that section, I have to understand how the whole DVCS work flow works, so that I can pick out just the little pieces that I need to make a simpler system -- the simpler system that subversion is. 
Of course, you may have trouble getting that section into the book, because a lot of what I've read starts by saying "You can't pretend it is subversion; you have to understand how the DVCS works". 

posted @ Monday, April 12, 2010 10:34 AM by Mark S

Mercurial is so easy. All the version control systems have the same basic commands: 
- check out  
- check in 
- diff 
Mercurial gives you a local repository so you can use version control your own work until it is good enough to push to a central repository. To me, that is the main difference between a distributed and non-distributed vcs. 

posted @ Monday, April 12, 2010 6:14 PM by Greg Strockbine

Comments have been closed for this article.

Follow Assembla

twitter facebook youtube linkedin googleplus

Subscribe by Email

Your email: