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

91–100 of 112 posts

Re: It’s time to stop using Subversion

#91

Post by eli »

dustingetz wrote: post #86
eli wrote: post #74

Earlier quoted context omitted.

But SVN really is fine. And Git definitely isn't better than SVN in "every way for every foreseeable usage." > We sometimes even actively try to deny others the very powers we refused to take. Huh? Who was that directed at?

I'd love to read a post where someone decided SVN is superior for their purpose, and their stance is defensible. I can't think of any reasonable use cases.

I'm not personally a big SVN defender/apologist, but I'll bite.

Imagine you're on a small team developing closed source software. Like many people, you already have SVN, your team already knows SVN, it's already integrated into build system and you're using Trac for ticketing. Based just on that, I would absolutely keep using SVN instead of transitioning to Git. Perhaps you disagree, but I hope you'll at least concede that's a reasonable position.

Re: It’s time to stop using Subversion

#92

Post by SupremumLimit »

cletus wrote: post #9
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.

The Jetbrains IDEs actually have excellent Git integration if that suits your purposes, which basically means Java (as many PHP, Python and Ruby programmers are married to simple text editors, emacs, vi, etc). Now I like git but I can totally see why people don't use it (or in fact any DVCS). The central repository model is easily understood and implemented. The idea that there is no central "source of truth" is conf…

Actually, I think Jetbrains RubyMine is a great IDE for Ruby and Rails apps too, so it's not just for Java. I love the Git integration because I haven't found a good Git GUI for Ubuntu.

Re: It’s time to stop using Subversion

#93

Post by nupark »

jshen wrote: post #90
nupark wrote: post #82

Earlier quoted context omitted.

What do you mean by 'sane', and how does subversion (which includes merge tracking) fail to meet your definition?

It's not a DAG. Since you know that subversion has merge tracking since 1.5 I'm going to assume you know what I mean. I don't have time or space in a comment to explain why this is so much better. For an example or two: http://stackoverflow.com/questions/2613525/what-makes-mergin... http://stackoverflow.com/questions/2475831/merging-hg-git-vs...

I don't have time or space in a comment to explain why this is so much better.

Better in practice, or better in theory? In practice, I personally haven't found that it makes a difference, and that the majority of cost in merging is in keeping abreast of functional differences, not in line-by-line conflict resolution.

YMMV, but I don't think it's as clear cut as you make it out to be.

Re: It’s time to stop using Subversion

#94

Post by dspillett »

calloc wrote: post #76
dspillett wrote: post #66

Earlier quoted context omitted.

This and more of the same. One loony (who I now thankfully don't have to put up with any more) was always making changes without merging them back into source control, meaning things were marked as addressed in issues logs but there was no corresponding update in the source tree. Lucky we were using a checkout-and-lock model at the time (small team, with each of us generally working on distcint areas, so this didn't…

Company I work at has everyone have their own clone server side, they then clone it locally, any changes they make get pushed back up to their clone on the server, from there they can ask for a merge request to merge it into mainline.

Aye, while he was still with us the chance to protect the central repository from any unverified changes from him was a very attractive idea. But given that he couldn't even file bug reports properly I'm not sure he would have coped with git.

Re: It’s time to stop using Subversion

#95

Post by glenjamin »

jmillikin wrote: post #60
glenjamin wrote: post #54

The large binary file thing keeps coming up again and again. I hear mercurial is working on support for these, but to my knowledge it's not something Git is overly concerned by. I keep seeing statements like "If you're storing large binary files in version control you're doing it wrong", which leaves me wondering - what's the generally accepted approach for versioning artwork. I'm mainly thinking about source formats…

PSD and PNG files are not usually counted as "large". When someone says "don't version large binary files", what they mean is "don't check in a DVD ISO of Fedora".

They may not suffer from the efficiency problems, but diffs and merges are still problematic. Is there any VCS tool designed to handle these sorts of things?

Re: It’s time to stop using Subversion

#96

Post by jshen »

nupark wrote: post #93
jshen wrote: post #90

Earlier quoted context omitted.

It's not a DAG. Since you know that subversion has merge tracking since 1.5 I'm going to assume you know what I mean. I don't have time or space in a comment to explain why this is so much better. For an example or two: http://stackoverflow.com/questions/2613525/what-makes-mergin... http://stackoverflow.com/questions/2475831/merging-hg-git-vs...

I don't have time or space in a comment to explain why this is so much better. Better in practice, or better in theory? In practice, I personally haven't found that it makes a difference, and that the majority of cost in merging is in keeping abreast of functional differences, not in line-by-line conflict resolution. YMMV, but I don't think it's as clear cut as you make it out to be.

Let's assume it isn't as clear cut as you say. That still leaves the question, why use an inferior tool? The argument that programmers are too dumb to reason about the distributed nature of a dvcs isn't a good argument to me. It took me one weekend with the pro git book for me to understand git well. That's a small price to pay for a superior tool.

Re: It’s time to stop using Subversion

#97

Post by nupark »

jshen wrote: post #96
nupark wrote: post #93

Earlier quoted context omitted.

I don't have time or space in a comment to explain why this is so much better. Better in practice, or better in theory? In practice, I personally haven't found that it makes a difference, and that the majority of cost in merging is in keeping abreast of functional differences, not in line-by-line conflict resolution. YMMV, but I don't think it's as clear cut as you make it out to be.

Let's assume it isn't as clear cut as you say. That still leaves the question, why use an inferior tool? The argument that programmers are too dumb to reason about the distributed nature of a dvcs isn't a good argument to me. It took me one weekend with the pro git book for me to understand git well. That's a small price to pay for a superior tool.

... That still leaves the question, why use an inferior tool?

This assumes that git has no significant practical drawbacks that might outweigh the constrained value of its merging support.

A bad car analogy: I never drive in the winter. I commute 1 hour each day to work. I have the choice between:

- A large SUV that gets 15 mpg but has traction control for handling icy winter roads and 16000 lbs of towing capacity

or

- A 30 mpg commuter car.

If we assume that subversion merging works fine (which, in large organizations, is my experience), then the next question is -- what feature(s), exactly warrants git's additional complexity? Why, in our organization, would we want to encourage people to create out-of-sight branches? What is the actual advantage to having individuals care about n-way merges?

Re: It’s time to stop using Subversion

#98

Post by jshen »

nupark wrote: post #97
jshen wrote: post #96

Earlier quoted context omitted.

Let's assume it isn't as clear cut as you say. That still leaves the question, why use an inferior tool? The argument that programmers are too dumb to reason about the distributed nature of a dvcs isn't a good argument to me. It took me one weekend with the pro git book for me to understand git well. That's a small price to pay for a superior tool.

... That still leaves the question, why use an inferior tool? This assumes that git has no significant practical drawbacks that might outweigh the constrained value of its merging support. A bad car analogy: I never drive in the winter. I commute 1 hour each day to work. I have the choice between: - A large SUV that gets 15 mpg but has traction control for handling icy winter roads and 16000 lbs of towing capacity or…

Subversion merging does not work fine. I guess you didn't read my links, so I won't spend more time on this.

Re: It’s time to stop using Subversion

#99

Post by nupark »

jshen wrote: post #98
nupark wrote: post #97

Earlier quoted context omitted.

... That still leaves the question, why use an inferior tool? This assumes that git has no significant practical drawbacks that might outweigh the constrained value of its merging support. A bad car analogy: I never drive in the winter. I commute 1 hour each day to work. I have the choice between: - A large SUV that gets 15 mpg but has traction control for handling icy winter roads and 16000 lbs of towing capacity or…

Subversion merging does not work fine. I guess you didn't read my links, so I won't spend more time on this.

I read your links. I also use subversion merging every day while maintaing feature and maintenance branches. It works fine and involves significantly less complexity than git.

Re: It’s time to stop using Subversion

#100

Post by jshen »

nupark wrote: post #99
jshen wrote: post #98

Earlier quoted context omitted.

Subversion merging does not work fine. I guess you didn't read my links, so I won't spend more time on this.

I read your links. I also use subversion merging every day while maintaing feature and maintenance branches. It works fine and involves significantly less complexity than git.

I use git everyday. I don't know what this complexity is you speak of. It took me a weekend to learn git, and about the same for subversion, but git gives me more flexibility and power.
Post reply on HN