He seems to be saying that svn is better than git because _some_ git users have a central repository they work against, and because they are planning on adding some features that might to some extent allow them to mimic a few things git already can do. That's just about the weakest argument for svn over git I've ever heard.
Then the went on to use the word "enterprise" about 10 times in 30 seconds. Not convincing.
The whole centralized vs distributed debate does not make much sense anyway, the choice of words is very poor. You almost always want to work on a common repository when working with other people - but the whole point of DVCS is that this common repository can be different for different usages (release vs development vs documentation vs testing ...). Something like subversion makes it very difficult to have several full fledge, synchronized repositories. Once you have a way to easily replicate live repo on the fly, you have already almost everything needed for a DVCS.
Also, something which is often overlooked: subversion was very poor even before DVCS came to light. It was only good at making sure everybody could work on the same snapshot. Branch management was inexistent not so long ago, no usable merge capabilities, awful interface to compare branches, etc... Just using git as a client to svn repository through git-svn already brings many advantages. Git-svn has saved me countless hours already compared to straight svn when working on public projects, especially for release management. svn log, blame, diff are slow to the point of being useless once you need to compare past revisions.
As an "enterprise" SVN user, I have to say I hate SVN "in the enterprise". Who the hell would want to rely on one repository in one location for all their writes? Not to mention delays in syncing changes read-only upstream creating confusion and loss in productivity for remote devs.
The HTTP method seems to be one of the most common uses in the "enterprise" because of its flexibility, but it's also the most buggy (in my experience). I know 'wandisco' makes its money off fixing all the typical "enterprise" problems with SVN, but we don't pay for 'wandisco' so we don't have the luxury of a proprietary fix for an open-source problem.
I have not used git. But the fact that it is distributed makes me want to try it a whole lot more.
They've ignored Git's superior branching scheme though. Once you use Git for a while and get a hang of branches, you won't want to go back to the Subversion way of doing it.
I believe that by "superior branching", DannoHung actually ment superior merging. That is something at which SVN is far, far behind DVCSs in general and GIT in particular.
Also, my experience, as non-representative as it is, has shown that cheap branching with efficient merging results in much less of a mess than everybody playing in the same sandbox and inevitably kicking everybody else's sand castles.
> "everybody playing in the same sandbox and inevitably kicking everybody else's sand castles."
That just points to poor collaboration management etc though. If people don't work together properly, you're just delaying problems until people merge anyway.
Not necessarily so. As I said, my experience may not be representative of the most common workflows, but in the company I'm working for people often work on experimental or tangential stuff but at the same time they want their changes to keep pace with the work on the main line. I that case they can't afford to sully the trunk and at the same time, because merging back a branch is a major pain, they can't fork off a branch, unless it is a significant enough chunk of functionality or code they are changing. No amount of "collaboration management" is going to make the situation any better, because all options result in some amount of pain for someone, pain makes people touchy, and touchiness makes people not work together properly.
Just as you believe that a proper social structure and sufficiently clear conventions can overcome deficiencies in software, I believe the oposite - the capabilities and limitations of software can enforce certain patterns of behavior. And in my experience DVCSs end up having more of a positive effect on the development process.
The big advantage of branches is to allow to break your commits into smaller things. When working on two new features which takes many commits, if you work on the same branch, the history becomes inter winded, and that's a nightmare to understand if you need to go back (or find regression). With branches that are pulled into a public reference branch, you are guaranteed to get a workable, coherent and consistent state. Without branches, what happens is either broken trunk or giant commits, both often worse than the (real) complexity brought by branch.
The fact that DVCS allows for less rigid management alo explains why DVCS became popular so quickly in open source, I think (where the kind of collaboration managements you suggest does not scale very well).
> "Without branches, what happens is either broken trunk or giant commits, both often worse than the (real) complexity brought by branch."
Or you do your development in a way that doesn't break the build, and do it in several steps.
For example, just build new code that can be specified to be used at runtime, then when it works just like the existing default code, switch it over (Effectively doing your own branch).
Dude, you're talking about expending extra effort and thought to be able to do something cleanly which the new tool lets you do effortlessly and mindlessly all to avoid something that the new tool is EXCELLENT at.
There are many situations where branches are the standard, conventional way of doings things: release managements, legacy development. Making branch hard does not make much sense - svn (with maybe cvs) are the only systems which make branch almost unusable. Every other system (including proprietary, non distributed ones) handle branch correctly.
Git made popular the use of branches for almost everything, but branches have been used way before DVCS became popular. It just happened to be that besides cvs/svn, all the non peculiar open source systems are DVCS, but working merge caps and branch managements are not specific to DVCS (but DVCS would be unusable without it).
Maybe I'm Doing It Wrong, but when I want to tag a release (or create a branch) in subversion, I have to make a copy of the entire codebase. When I want to tag a release in git, it just creates a pointer to a revision. It's far less annoying for the next person who needs to checkout the code.
Branching was a pain for me when using SVN - far too much hassle to keep on top of it all; All branches are visible to everyone and merging between them was slow.
With Git, branching is simple and really fast. It can also be done in such a way as to prevent your own personal development and feature branches from making it back into the central repo.
I've also found that cherry picking commits between branches and squishing small commits help me maintain the cleanliness of our repos (At no point in the history of our central repo is there half of a new feature or fix).
Branching in Subversion is easy, it's the merging part that's difficult. That's because branches in Subversion are just copied folders that it tries to keep in sync with some magic "glued on" metadata attributes. (At least they were the last time I checked.)
In Git, branches are an inherent part of the repository graph structure. So the relationships of branches and merges are very low level and stable and work quite reliably in all situations.
Because of this I trust Git more for branching/merging.
The problem is that svn makes branching easy, but merging very hard. This provides an incentive to postpone merges which of course makes them even harder once the excuses run out and they have to be done. Distributed SCMs recognize that branching is necessary, but actually provide the tools to make merging easy. Once merging is easy, branching doesn't look bad any more.
It still looks bad to me. I want 1 codebase, developed linearly.
Definitely I can see the appeal of branches for software you ship, where you need to bug fix an old version and release a patched ver etc, but I can't really see the need for web based software, which I think is pretty usually developed linearly without much mess.
I much prefer doing branches in the source code (If that makes sense).
For example say you have a widget and you want to try a different strategy, create a newWidget in the source, make it so you can swap it in and out of the runtime maybe for testing. Keep developing it, until you're sure it's cool. When cool, replace widget with newWidget. If it doesn't work out, just delete it.
Then, when you want to commit your branch, rebase the branch from your master before merging. Then, when you merge, the patches will show up all in a row at the point you commit, as if they were all done in a row. Essentially, this is exactly what happens when you are working with subversion for a couple of days and then do several commits at the end.
Except you can trivially have multiple of these things going at a time.
I'm going to ask you a question: Have you actually tried git or anything for a significant period of time, like, at least a couple weeks? (Not just "yeah, 5 minutes.") If not, I'd point out that you're speculating about how git might affect workflow to people who actually know how git affects workflow, since they are living it. (And if so, you're not doing a great job of showing that you tried it.)
"Yes, I do this with svn easily enough (Local install of svn). Simple enough..."
Yeah Right :-P
Obviously I meant if you were working on a project with its repository on a remote server. Assuming you want local version control (as you seemt o do, since you are locally installing svn) you'd maintain a separate local repository, maintain the same project under both, and synch them both when you get back online?
And if you had two laptops say (apart from the remote server) , you'd maintain 3 repositories?
I use branches in Hecl to play around with experimental features. These are things that I want to keep around for a while, hack on, but that are not ready to be in Hecl proper. If I had to wait for a yes/no on those features to go on with other things, it would slow things down.
This is something I don't fully understand. How does it make merging more easy?
I tried mercurial some time ago and it gave me conflicts for very easy merges. While I like it very much as a local version control for myself this merging was really bad. Now its not unlikely that I made a mistake somehow. But why should merging be more easy with git/Mercurial than with SVN?
Before 1.5, svn had no real merge capability. In particular, it could not detect that you merged something already when merging a changeset. Also, the merge command effectively "squashed" everything - you could use svnmerge and co to get something a bit better, but the tools were very poor to say the least.
Technically speaking, svn merge is more akin to cherry-pick in git/hg/etc..., where the "merged" commits are not recorded as such, but as totally new commits.
Note also that bad svn merging capabilities are specific to svn, not to centralized VCS (perforce, etc...). It is not so much that DVCS are better than svn as much as svn worse than everything else.
Except that in subversion, branching is a great way to lose revision history. I think this is partly fixed with the merge tracking features in the more recent subversion, but in git it is simple - it just works like you'd expect.
I used to think like you back when using svn... Now I think that when using svn, branching causes a mess and for that reason is bad... But, it's amazingly convenient and simple to use with git
I didn't mean that I believe branches in svn are a mess. I mean that the concept of using branches IMHO is messy and should be avoided. I just don't like that workflow at all. I don't think it's good for productivity.
Came across as excuses as why the subversion design was so inflexible and how it's going to change.
Painting a picture that distributed version control systems learnt from subversion is rubbish. These technologies were developed over the same period: bitkeeper's development started some time in 1997.
He also talks about the upcoming changes in Subversion, such as Working Copy Next Generation (WC-NG), which he believes will cause a number of Git users to convert back to Subversion.
If I've already left for git (or other dvcs) why would I come back just for "working copy"? I moved on from Subversion for much more than that...
I always hated the way svn left its .svn cruft all over the place. Glad to see they're trying to get away from it with version 1.7 but it's the same kind of glad as seeing someone try to make an iPod killer.
I literally thought this video was a joke for the first couple minutes. But then it wasn't very funny, and I realized "holy crap, this guy is serious." I don't know what else to say.
Improving subversion borrowing some "distributed feature" from git&co? I'm not sure of how many would care...
The thing that make svn a "toy" scm is the branching model/facilities(e.g. merge) and this is the area that seriously needs to be improved. Do you want to bring svn "to the enterprise"?
Start offering what other enterprise scms offer, take clearcase for example, it has its issues but the branch/merge facilities are great.
Not for nothing, but Wandisco sells $1000/seat software that makes Subversion distributed (i.e. more like Git).
I checked it out about three years ago (before Git was on my radar) when the company I worked for brought on some offshore developers, and they were on a slow and unstable internet connection.
Then the went on to use the word "enterprise" about 10 times in 30 seconds. Not convincing.