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

51–60 of 112 posts

Re: It’s time to stop using Subversion

#51

Post by bad_user »

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've never* seen a user-facing command that 
     causes Subversion to become mystically wedged 
     and require a new repository for non-advanced users.
It happened to me 3 times already, with my local copy ending up in limbo - as weird stuff can happen when you're deleting a directory locally, with another dev having made changes to its files.

And torching .git and starting over is easier than doing the same with SVN ;)

That's why I'm using git-svn; even when I have to use SVN.

Re: It’s time to stop using Subversion

#52

Post by jshen »

hollerith wrote: post #38
jshen wrote: post #29

Earlier quoted context omitted.

It sounds like you were training people on git when you didn't know git very well. That's an odd way to judge git.

Not if he put equal amounts of effort into learning git, svn and hg.

If someone says svn is easier it's because they don't do significant branching. Git and hg allow you to branch sanely. Subversion doesn't. Someone that doesn't get this hasn't learned much.

Re: It’s time to stop using Subversion

#53

Post by kenjackson »

Aegean wrote: post #27
selectnull wrote: post #17

Earlier quoted context omitted.

"someone always has it worse." Unfortunatelly, not in your case. ;)

What was the name of that version control tool before CVS, RVCS? Back in 2007 I had heard one very big name hardware company using that for version control and planning to move to CVS as they thought the former was beginning to show its age.

I used SCCS in the 80s. Not sure if that was the one you're talking about though.

Re: It’s time to stop using Subversion

#54

Post by glenjamin »

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 like PSD or fireworks PNGs.

Re: It’s time to stop using Subversion

#55

Post by mduerksen »

nupark wrote: post #43
mduerksen wrote: post #22

Earlier quoted context omitted.

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

Well, in my case it's not a submarine, but a train.

And yes, it is great advantage that I can freely make a branch with the new feature that I just started working on, without having to summon a meeting to let everyone know that a new branch will be created, which is not intended to be used by anyone else even if it's visible to everyone.

Re: It’s time to stop using Subversion

#56

Post by kabdib »

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…

> (Isn't version control mostly for text files?)

No. For long-life projects I snapshot entire build systems (toolsets, documentation, you name it) so that a precise image can be re-created later.

Re: It’s time to stop using Subversion

#57

Post by jarin »

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.

I had a coworker who was super resistant to switching to git because of the command line thing. I decided to give him a walkthrough in the hopes that I could answer any questions. You know what the problem turned out to be? He didn't know about tab-completion on the command line.

Re: It’s time to stop using Subversion

#58

Post by loup-vaillant »

selectnull wrote: post #3

I'm kinda annoyed that every once in a while, somebody has to come along dissing svn, prophesying its inevitable demise and glorifying git. Yes, git is "better" than svn, I agree. I like the message in general, but I don't like the tone of it. I still use svn. For personal project, I have moved to hg. I use git occasionally. They all have its merits, and svn certainly didn't deserve "you should probably stop using it…

> They all have [their] merits

That is a poisonous meme which should be fought tooth and nail. It basically follows the structure of the fallacy of grey¹: "every tool has qualities, therefore they're all fine".

It doesn't account for the fact that some tools dominate others. Meaning, they are demonstrably better in every way for every foreseeable usage. But we tend to cling to our old ways, instead of just saying "oops"² in exchange for new powers. We sometimes even actively try to deny others the very powers we refused to take.

Here, you were very close to make that mistake about svn vs Git/Hg/Darcs. Git doesn't dominates svn yet, but I'm sure it will. Then, subversion will deserve "you should stop using it".

But most often, this mistake is made with programming languages (it's a variation on the blub paradox). And the effects are far worse there.

[1]: http://wiki.lesswrong.com/wiki/Fallacy_of_gray

[2]:http://wiki.lesswrong.com/wiki/Oops

Re: It’s time to stop using Subversion

#59

Post by abyssknight »

dexen wrote: post #21
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…

You are mistaking the tools you use for the tools that a team can use. That's Git: it lets teammates communicate changes in a straightforward, consistent manner, with little overhead. With a tool suite to review, pull en mass or cherry-pick the changes at will; with the defaults being the most practical choices most of the time. If you want your team to be more than a sum of the members (as opposed to stepping on eac…

Just to play devil's advocate here, and definitely not disagreeing with you, but...

Do you know how we communicated changes before git and other team tools? With our voices, markers, and boards. If your team steps on each other's toes, might that not be a problem with the team dynamics and not necessarily the tools themselves?

Re: It’s time to stop using Subversion

#60

Post by jmillikin »

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