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

It’s time to stop using Subversion

altdevblogaday.org

Post reply on HN
Print view View original

41–50 of 112 posts

Re: It’s time to stop using Subversion

#41

Post by jarin »

edabobojr wrote: post #19

The big risk I always see with git is that you start storing more and more work locally. This exposes you to the chance of hardware failure on a desktop pc. With svn, it would be easier for the hardware to be redundant and backed-up.

It's not hard to push topic branches to origin and delete them when they're done (although admittedly the syntax to delete a remote branch is a little strange).

Just because the user has a risk of doing that doesn't reflect badly on the tool, though. It's like saying that the big risk of a knife is that you'll cut yourself if you're not careful.

Re: It’s time to stop using Subversion

#42

Post by dustingetz »

durin42 wrote: post #20
yuvadam wrote: post #11

Do not confuse elitism with minimalism. Git is simply easier to use, and harder to shoot yourself in the foot with - at least when it comes to the basic flows. (Granted, you can blow your face off with git if you really try hard). When branching in git is a simple git checkout -b newbranch away as opposed to svn copy http://repo.com/some/path/to/trunk http://repo.com/some/path/to/branches/somenewbranch - then what el…

> Git is simply easier to use, and harder to shoot yourself in the foot with - at least when it comes to the basic flows. (Granted, you can blow your face off with git if you really try hard). I don't know. I've trained a lot of developers with Subverison, Git, and Mercurial. Subversion is the one that I've honestly had the least trouble with, and Git the most. Heck, early on with git I had instances where the repo w…

i'd love to see a blog post on this, because im probably leading a migration at work and I can't think of a situation like that.

Re: It’s time to stop using Subversion

#43

Post by nupark »

mduerksen wrote: post #22
abyssknight wrote: post #7

How about, no? The day you realize the tools you use are not the most important part of your function is the day you finally understand what it is you do. Yes, tools can make things easier, run more smoothly, or make you happy but... Can you do the same, if not better, job with alternate, less efficient tools? Yes. Tool elitism is no better than language elitism. Now, I'll be in the corner using notepad and copying m…

> Can you do the same, if not better, job with alternate, less efficient tools? The question is: Is a tool just 10% more efficient or does it introduce a whole new quality of working with it? What do you do when your already delivered software has a bug that needs to be fixed urgently, but you already started to add new features that are not ready yet? Using branches with svn is a thing just everyone is scared of (an…

I don't understand the branching mantra that I hear from git proponents. Subversion has had merge tracking since 1.5, and with it, branching and method is as painless as it can reasonably be.

Unless you want to work on a submarine, or have an organizational need for people to maintain private unpublished branches (eg, open source), I don't really see what advantages git has to offer over subversion in organizational (read: corporate) development.

Re: It’s time to stop using Subversion

#44

Post by nupark »

dexen wrote: post #23
durin42 wrote: post #20

Earlier quoted context omitted.

> Git is simply easier to use, and harder to shoot yourself in the foot with - at least when it comes to the basic flows. (Granted, you can blow your face off with git if you really try hard). I don't know. I've trained a lot of developers with Subverison, Git, and Mercurial. Subversion is the one that I've honestly had the least trouble with, and Git the most. Heck, early on with git I had instances where the repo w…

Perhaps you want to re-read on git-reset. You can always rewind history to some arbitrary point and re-stack operations, both en-mass and step by step You can re-write branches locally and even on the server. It's to be used very rarely & carefully, but it has gotten the other team at my workplace out of a tight spot just two days ago.

Whereas with a simpler tool like subversion, there will be no tight spots.

Re: It’s time to stop using Subversion

#45

Post by pilif »

jarin wrote: post #36
yawgmoth wrote: post #30

Earlier quoted context omitted.

It seems to me that a lot of the evangelists of one source control tool over another fail to realize that for companies that -aren't- startups, migrating between tools is a lot of work. Reconfiguring build servers, rewriting documentation/wiki pages which have SVN Uris (or anything at all regarding existing source control) in them for projects that have existed 5-10 years as well as having an entire team learn a new…

In my experience, going from SVN to Git has been as simple as doing git-svn clone and then pushing up to Github (or Assembla). Then again, I agree that there's a lot for the users to learn, so it's probably best done during a refactoring phase and you need at least one Git master to be available to answer any questions.

The migration on a technical level is easy.

I did spend multiple hours though fixing non-fast-forwarded merges, accidentally created merges after pulling, incorrect author names and one accidental force-push.

All of these I could have prevented using policy on the server, but I would still have had to help explaining the underlying issues in order to a) get the broken commit in and b) make sure it doesn't happen again. Explaining takes much longer than just fixing.

The problem isn't technical. It's human.

The more employees/team members you have, the more complicated it will become to put all on the same boat. My experience above comes from a team with 4 people of which two were already git users (one of them was me).

I don't want to think what this migration would have meant if we were 10 or even 100 people.

Re: It’s time to stop using Subversion

#46

Post by pilif »

selectnull wrote: post #32
yawgmoth wrote: post #30

Earlier quoted context omitted.

It seems to me that a lot of the evangelists of one source control tool over another fail to realize that for companies that -aren't- startups, migrating between tools is a lot of work. Reconfiguring build servers, rewriting documentation/wiki pages which have SVN Uris (or anything at all regarding existing source control) in them for projects that have existed 5-10 years as well as having an entire team learn a new…

Exactly! I have 15 GB of svn repositories. I don't plan to migrate them. I use mercurial for new projects and I'm fine with old stuff to live in svn. Just like I use more than one programming language, I use more than one OS, I use more than one database backend...

Whenever I'm touching one of my old projects (some even in CVS), I'm migrating them to the system I'm using at the time.

Currently that's git.

So now I'm looking back on 52 repositories. 16 in CVS, 14 in subversion and 22 in git (all of them counted only once) created over the last 10 years.

Re: It’s time to stop using Subversion

#47

Post by btucker »

henrikschroder wrote: post #28
btucker wrote: post #18

As someone who got started in this field about 10 years ago, I find the mass-adoption of and then mass-exodus from subversion fascinating. I remember sitting in the audience for a talk by Greg Stein introducing subversion at ApacheCon ('02 maybe) and being wow'ed. I'm trying to think if there's another piece of architecture our industry has both so universally embraced & discarded (hyperbole, I know) in the last deca…

It's because 10 years ago there weren't really any distributed version control systems, and the original aim of Subversion was to fix everything that was horribly broken in CVS. They definitely succeded with that design goal, but since they're stuck in a centralized design, there's nothing they can do to move it to a distributed model, and it's not something that could have been foreseen 10 years ago. They're simply…

I agree that's what happened. But I'm still trying to think of whether there are any other cases of this in the last decade. There certainly have been other paradigm shifts. Yet i'm having a hard time thinking of anything which both gained significant prominence and then was left behind. Maybe OpenID?

Re: It’s time to stop using Subversion

#48

Post by jevinskie »

edabobojr wrote: post #19

The big risk I always see with git is that you start storing more and more work locally. This exposes you to the chance of hardware failure on a desktop pc. With svn, it would be easier for the hardware to be redundant and backed-up.

I fail to see your point. Every copy of a git repo is a full copy [1] - unlike a svn checkout. If you follow a centralized server model with git you have a copy on the server and every workstation it is checked out on. With svn, the full repo only exists on the server. Why couldn't you have a redundant, backed up central git server?

[1] Not a substitute for real backups of your repo!

Re: It’s time to stop using Subversion

#49

Post by mortice »

mcantor wrote: post #34

> If I'm committing some large assets... (Isn't version control mostly for text files?) > If, while the upload's been happening, I've made more changes to my working copy... (So you're uploading a large--presumably binary--file, and you're continuing to work on it while it's committing...) > I have to carefully pick out my new changes and keep them separate from my old changes. (Wait, what? In a binary file? Or did y…

The article and your comment share the same deficiency: they don't deal with concrete problems (or at least when the article does it's about edge cases, as you point out). It's all very well for you to have decided that svn > git for your purposes, and I applaud you for having evaluated the two and chosen one based on relative merits. But in order to extrapolate from that to a general counter-argument to "git is better than subversion," you need to a) provide the details of the problems you had with git and b) explain how they are specimens of a general problem which SVN doesn't have.

I don't say this as a git fanboy, just as a techie who hears "I had problems" and instantly wants to hear details so that I can evaluate the argument properly.

Re: It’s time to stop using Subversion

#50

Post by kenjackson »

yellowbkpk wrote: post #6

Having just spent the last month converting our operation to Git here at work, I can tell you the main force in keeping Subversion around are Windows users who are used to TortoiseSVN. There still is no viable Git UI for Windows (or any other OS, really -- but Windows is especially immature) and the people who make decisions a) use Windows and b) "don't have time" to learn git on the command line.

This is my big problem with Git. TortoiseSVN is extremely well done and fits nicely in my workflow. With Git it feels like a hack. W/o better tools support Git is probably dead on Windows and Mercurial win the Windows world.

Also Git's CR/LF issues on Windows are a pain. The fact that I've never seen an issue with them on any other SCCS, and they seem to cause headaches with Git is another reason it'll have trouble catching on in a big way.

Post reply on HN