Live data from Hacker News

Why Subversion is better than Git

subversion.wandisco.com

41–47 of 47 posts

Re: Why Subversion is better than Git

#41
post #18

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.

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.

Re: Why Subversion is better than Git

#42
post #37
post #18

Earlier quoted context omitted.

> "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 stat…

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

Re: Why Subversion is better than Git

#43
post #38

Earlier quoted context omitted.

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

Yes, I do this with svn easily enough (Local install of svn). Simple enough...

Maybe that's a good selling point for people who aren't connected to the net much though,

Re: Why Subversion is better than Git

#44
post #43

Earlier quoted context omitted.

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

Yes, I do this with svn easily enough (Local install of svn). Simple enough... Maybe that's a good selling point for people who aren't connected to the net much though,

"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?

Re: Why Subversion is better than Git

#45
post #43

Earlier quoted context omitted.

Yes, I do this with svn easily enough (Local install of svn). Simple enough... Maybe that's a good selling point for people who aren't connected to the net much though,

"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…

It's not really a use case I have. If I'm working, I have internet connectivity :/

Re: Why Subversion is better than Git

#46
post #42
post #37

Earlier quoted context omitted.

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 stat…

> "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.
Post reply on HN