Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Subversion is better than Git

subversion.wandisco.com

Post reply on HN
Print view View original

31–40 of 47 posts

Re: Why Subversion is better than Git

#31

Post by cdavid »

mru wrote: post #8

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.

Re: Why Subversion is better than Git

#32

Post by ulrich »

jedbrown wrote: post #23
axod wrote: post #11

Earlier quoted context omitted.

FWIW, I'm of the school of thought that branching is bad, causes mess, and should be hard. Having said that, branching seems pretty simple in svn if you really like having them.

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.

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?

Re: Why Subversion is better than Git

#34

Post by rnicholson »

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...

Re: Why Subversion is better than Git

#35

Post by cdavid »

axod wrote: post #11
DannoHung wrote: post #4

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.

FWIW, I'm of the school of thought that branching is bad, causes mess, and should be hard. Having said that, branching seems pretty simple in svn if you really like having them.

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).

Re: Why Subversion is better than Git

#36

Post by jerf »

axod wrote: post #27
jedbrown wrote: post #23

Earlier quoted context omitted.

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…

"I want 1 codebase, developed linearly."

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.)

Re: Why Subversion is better than Git

#37

Post by cdavid »

axod wrote: post #18
lurch_mojoff wrote: post #14

Earlier quoted context omitted.

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.

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).

Re: Why Subversion is better than Git

#38

Post by axod »

jerf wrote: post #36
axod wrote: post #27

Earlier quoted context omitted.

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…

"I want 1 codebase, developed linearly." 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…

Yes I tried it for a day (Not long I agree). It looked like a reasonably copy of svn, but it didn't offer me anything.

Let me restate: I do not like branches and use them very rarely.

So, to the guy who hates branches, what does git offer me over svn (Which does all I need at the moment)?

Re: Why Subversion is better than Git

#39

Post by cdavid »

ulrich wrote: post #32
jedbrown wrote: post #23

Earlier quoted context omitted.

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.

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.

Re: Why Subversion is better than Git

#40

Post by plinkplonk »

axod wrote: post #38
jerf wrote: post #36

Earlier quoted context omitted.

"I want 1 codebase, developed linearly." 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…

Yes I tried it for a day (Not long I agree). It looked like a reasonably copy of svn, but it didn't offer me anything. Let me restate: I do not like branches and use them very rarely. So, to the guy who hates branches, what does git offer me over svn (Which does all I need at the moment)?

"So, to the guy who hates branches, what does git offer me over svn (Which does all I need at the moment)?"

The ability to version control your project (even without branching you can checkin) when disconnected (from your network).

Post reply on HN