11 ms·

It’s time to stop using Subversion

51 points by fogus 16y ago

Aegean 16y ago
Very old news.
- jdludlow 16y ago
  Indeed. When I clicked the article link, I expected to find something from ~2007.
- spacemanaki 16y ago
  And yet some of us are stuck using CVS.
  - CountHackulus 16y ago
    Some of us are stuck using Clear Case or Visual Source Safe. Whatever source control you're using, someone always has it worse.
    - selectnull 16y ago
      "someone always has it worse." Unfortunatelly, not in your case. ;)
      - Aegean 16y ago
        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.
        edabobojr 16y ago
        Or you could talk to Joe down the hall. He has the 'gold' version of the source code on his desktop. Don't forget to send him your changes when you are done and he will integrate it to the current 'gold' version.
        kenjackson 16y ago
        I used SCCS in the 80s. Not sure if that was the one you're talking about though.
        gacba 16y ago
        You're thinking of RCS: http://en.wikipedia.org/wiki/Revision_Control_System http://en.wikipedia.org/wiki/Revision_Control_System
    - danssig 16y ago
      I would rather have Clear Case than SVN. As bad as it is, at least it can branch and merge.
    - _djo_ 16y ago
      The company I'm working at actually moved to ClearCase a couple of years back. It's the most painful development tool that I have ever used and I pity any future victims of IBM's marketing skill who choose to adopt it.
    - supirman 16y ago
      "someone always has it worse"... That was my previous place of employment: in-house perl scripts wrapped around RCS. Absolute nightmare.
selectnull 16y ago
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".
- hsmyers 16y ago
  It is almost as if there is a law of geek nature that says 'For every evangelist there must be a troll...' It is hard to appreciate the useful content when combined with gratuitous attacks.
- yawgmoth 16y ago
  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 source control tool is no task to be taken lightly.
  - selectnull 16y ago
    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...
    - pilif 16y ago
      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.
yellowbkpk 16y ago
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.
- jmaygarden 16y ago
  That's exactly why we had to go with Mercurial instead of git. Their Windows integration is approaching SVN. Plus we were already using FogBugz. So, Kiln was a plus.
- cletus 16y ago
  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 confusing--possibly even alarming--to an outsider. Windows support problems for Git go beyond having no TortoiseSVN equivalent though. When I was setting this up I at first tried to get Git over SSH working with PuTTY and it a hair-pulling out experience. I eventually abandoned that effort in favour of Cygwin, which just worked.
  - SupremumLimit 16y ago
    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.
- MindTwister 16y ago
  How about TortoiseGit? http://code.google.com/p/tortoisegit/ http://code.google.com/p/tortoisegit/
abyssknight 16y ago
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 my file every time I make a major change. ;)
- dexen 16y ago
  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 each others' toes), you need decent communication tool. Or you can dispose of communication by being a lone wolf.
  - abyssknight 16y ago
    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?
    - danssig 16y ago
      The easier you make things for people the less likely they are to mess it up. We used to get around by horse and buggy but I think you'd agree that a change in tools has been a benefit that lets us do things we couldn't do before, wouldn't because it was too hard or tried to do but failed often from the same mistakes over and over.
    - dexen 16y ago
      Those are not the changes you are looking for :-) You are absolutely right about the way to propagate changes in ideas, prerequisites, protocols etc. etc.. Actually, I'm a frequent whiteboard user myself. I should've made myself clear I was meaning the physical changes to the implementation files; in any case, something that is byproduct of information shared verbally.
pdenya 16y ago
Why do some devs not like CLIs? GUIs are nice sometimes but I definitely don't pick my tools based on which has the nicest. Also, it's not like SVN is suddenly bad or anything. I prefer GIT but I'm not tripping all over myself to switch over all of my existing projects.
- Tomek_ 16y ago
  CLIs are nice once you remember commands to use them and usually devs have more important things to do than to learn another set of commands.
yuvadam 16y ago
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/trunk http://repo.com/some/path/to/branches/somenewbranch http://repo.com/some/path/to/branches/somenewbranch - then what else is there to say, really? Sure, svn is extremely easy to setup and use in small teams. But it is simply not geared towards modern development flows. I appreciate tools that appreciate my time (and sanity) as a developer. And git does just that.
- durin42 16y ago
  > 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 was so wedged I had to just torch .git and start over. I know more now and can get out of it, but with Subversion I've never* seen a user-facing command that causes Subversion to become mystically wedged and require a new repository for non-advanced users.
  - dexen 16y ago
    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.
    - nupark 16y ago
      Whereas with a simpler tool like subversion, there will be no tight spots.
JulianMorrison 16y ago
Also: .gitignore is fundamentally saner than svn:ignore properties. You can commit it, or not. You can add to it locally without adding it into your next commit. You can make it ignore itself. It applies recursively.
btucker 16y ago
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 decade.
- v21 16y ago
  I have friends still who use CVS (and don't see why it's so bad). In fact, we still have CVS repos around. Change is slooow.
- dexen 16y ago
  The plans Subversion developers had were very promising; but the implementation wasn't that good and some non-obvious but handy features were missed. The enchanted users flocked to Subversion in hopes of it improving over time. The disillusioned users jump the ship once they learn of better alternatives. Embraced and discarded? With a little hyperbole, and two decades of time scale, that's Win32. Startups used to do Win32 programs by default, now it's web. Of course big, hulkin' companies still do...
- henrikschroder 16y ago
  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 the last technology before a paradigm shift, and that's never a good position to be in.
  - selectnull 16y ago
    I think that's the best position (in case of svn) to be in. Subversion is, imho, the best of centralized scm-s. There are many companies that, for some reason or other, will not switch to dvcs. It really doesn't matter that distributed model is better than centralized, some people will not switch over. And svn is great choice for them.
edabobojr 16y ago
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.
- jarin 16y ago
  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.
- jevinskie 16y ago
  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!
  - edabobojr 16y ago
    Whenever people talk about git, they seem to talk about how you can have all of these working copies locally. My concern is the frequency with which code would be published to the centralized server and possible loss if all of the working copies were to disappear. Admittedly, this is a bigger problem in svn if you aren't using branches for work-in-progress.
- dspillett 16y ago
  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 work out too inconvenient as it can do with larger teams) meaning we could see what files he had checked out. And sometimes he'd just edit local copies of files without checking them out/in at all, and often "lost" updates somehow (usually, I think, accidentally overwriting them with the source controlled versions he'd not updated). <Deity> alone knows how much confusion he could have caused with his own local repository. He might have worked for weeks without pushing to elsewhere then lose the whole local repo. Then again I usually felt safer if his work wasn't in source control anyway. I often thought it might be quicker to stay late and do the work myself from the start instead of staying late fixing his work as often as I needed to...
binarysoul 16y ago
a simpler solution, use git-svn
- jarin 16y ago
  Any time I take on a client project that uses SVN, I always use git-svn. Once you get used to working with git-flow and feature branches, you never go back.
mcantor 16y ago
> 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 you commit the binary file and changes to smaller text files in the same changeset? If so, you should be committing them separately. Either you're making small commits to text files that commit almost instantly, or you're making large commits to binary files that you can't "pick out" changes from anyway. Gotta pick one.) > As soon as the commit is published, other people may check it out and try building it... > ... if I can't access the repository server – if it's gone down, or if I'm working remotely – then I can't commit at all. > ... but there are many reports [weasel words] of it being somewhat prone to error. If your mergeinfo property has been corrupted somehow, it might be extremely hard to spot... I see a lot of inconclusive beating around the bush here. The author doesn't want to come out and say that any of these are concrete showstoppers because they are all, at worst, edge cases that experienced svn users mostly know how to deal with anyway. Every VCS has its own bugbears like these, git included. I have been using subversion for years; I do all kinds of insane nonsense with private branches, merging and merge-tracking, large asset commits and all of the things this article uses for its doomsaying. I run into big problems maybe two or three times a year. The writer suggests that git is better. For some reason, even though I have read numerous manuals and guides about git, and have grilled git experts, and have regularly used git myself, and presumably understand how it works, I have to go on a farcical journey into its implementation details every time I do ANYTHING. I always end up in #git, or calling a more git-savvy friend. Everyone inevitably has a different answer that involves a lot of shrugging and "Oh, I guess this actually happened." This was the result even when all I did was follow the instructions at help.github.com/forking, TO THE LETTER. Perhaps I am just a moron, and subversion is just VCS for morons. If so, I am too far gone to realize.
- mortice 16y ago
  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.
glenjamin 16y ago
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.
- jmillikin 16y ago
  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".
  - glenjamin 16y ago
    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?

51 points by fogus 16y ago

Aegean 16y ago

Very old news.

jdludlow 16y ago
Indeed. When I clicked the article link, I expected to find something from ~2007.
spacemanaki 16y ago
And yet some of us are stuck using CVS.
- CountHackulus 16y ago
  Some of us are stuck using Clear Case or Visual Source Safe. Whatever source control you're using, someone always has it worse.
  - selectnull 16y ago
    "someone always has it worse." Unfortunatelly, not in your case. ;)
    - Aegean 16y ago
      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.
      - edabobojr 16y ago
        Or you could talk to Joe down the hall. He has the 'gold' version of the source code on his desktop. Don't forget to send him your changes when you are done and he will integrate it to the current 'gold' version.
      - kenjackson 16y ago
        I used SCCS in the 80s. Not sure if that was the one you're talking about though.
      - gacba 16y ago
        You're thinking of RCS: http://en.wikipedia.org/wiki/Revision_Control_System http://en.wikipedia.org/wiki/Revision_Control_System
  - danssig 16y ago
    I would rather have Clear Case than SVN. As bad as it is, at least it can branch and merge.
  - _djo_ 16y ago
    The company I'm working at actually moved to ClearCase a couple of years back. It's the most painful development tool that I have ever used and I pity any future victims of IBM's marketing skill who choose to adopt it.
  - supirman 16y ago
    "someone always has it worse"... That was my previous place of employment: in-house perl scripts wrapped around RCS. Absolute nightmare.

selectnull 16y ago

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

hsmyers 16y ago
It is almost as if there is a law of geek nature that says 'For every evangelist there must be a troll...' It is hard to appreciate the useful content when combined with gratuitous attacks.
yawgmoth 16y ago
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 source control tool is no task to be taken lightly.
- selectnull 16y ago
  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...
  - pilif 16y ago
    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.

yellowbkpk 16y ago

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.

jmaygarden 16y ago
That's exactly why we had to go with Mercurial instead of git. Their Windows integration is approaching SVN. Plus we were already using FogBugz. So, Kiln was a plus.
cletus 16y ago
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 confusing--possibly even alarming--to an outsider. Windows support problems for Git go beyond having no TortoiseSVN equivalent though. When I was setting this up I at first tried to get Git over SSH working with PuTTY and it a hair-pulling out experience. I eventually abandoned that effort in favour of Cygwin, which just worked.
- SupremumLimit 16y ago
  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.
MindTwister 16y ago
How about TortoiseGit? http://code.google.com/p/tortoisegit/ http://code.google.com/p/tortoisegit/

abyssknight 16y ago

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 my file every time I make a major change. ;)

dexen 16y ago
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 each others' toes), you need decent communication tool. Or you can dispose of communication by being a lone wolf.
- abyssknight 16y ago
  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?
  - danssig 16y ago
    The easier you make things for people the less likely they are to mess it up. We used to get around by horse and buggy but I think you'd agree that a change in tools has been a benefit that lets us do things we couldn't do before, wouldn't because it was too hard or tried to do but failed often from the same mistakes over and over.
  - dexen 16y ago
    Those are not the changes you are looking for :-) You are absolutely right about the way to propagate changes in ideas, prerequisites, protocols etc. etc.. Actually, I'm a frequent whiteboard user myself. I should've made myself clear I was meaning the physical changes to the implementation files; in any case, something that is byproduct of information shared verbally.

pdenya 16y ago

Why do some devs not like CLIs? GUIs are nice sometimes but I definitely don't pick my tools based on which has the nicest. Also, it's not like SVN is suddenly bad or anything. I prefer GIT but I'm not tripping all over myself to switch over all of my existing projects.

Tomek_ 16y ago
CLIs are nice once you remember commands to use them and usually devs have more important things to do than to learn another set of commands.

yuvadam 16y ago

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/trunk http://repo.com/some/path/to/branches/somenewbranch http://repo.com/some/path/to/branches/somenewbranch - then what else is there to say, really? Sure, svn is extremely easy to setup and use in small teams. But it is simply not geared towards modern development flows. I appreciate tools that appreciate my time (and sanity) as a developer. And git does just that.

durin42 16y ago
> 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 was so wedged I had to just torch .git and start over. I know more now and can get out of it, but with Subversion I've never* seen a user-facing command that causes Subversion to become mystically wedged and require a new repository for non-advanced users.
- dexen 16y ago
  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.
  - nupark 16y ago
    Whereas with a simpler tool like subversion, there will be no tight spots.

JulianMorrison 16y ago

Also: .gitignore is fundamentally saner than svn:ignore properties. You can commit it, or not. You can add to it locally without adding it into your next commit. You can make it ignore itself. It applies recursively.

btucker 16y ago

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

v21 16y ago
I have friends still who use CVS (and don't see why it's so bad). In fact, we still have CVS repos around. Change is slooow.
dexen 16y ago
The plans Subversion developers had were very promising; but the implementation wasn't that good and some non-obvious but handy features were missed. The enchanted users flocked to Subversion in hopes of it improving over time. The disillusioned users jump the ship once they learn of better alternatives. Embraced and discarded? With a little hyperbole, and two decades of time scale, that's Win32. Startups used to do Win32 programs by default, now it's web. Of course big, hulkin' companies still do...
henrikschroder 16y ago
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 the last technology before a paradigm shift, and that's never a good position to be in.
- selectnull 16y ago
  I think that's the best position (in case of svn) to be in. Subversion is, imho, the best of centralized scm-s. There are many companies that, for some reason or other, will not switch to dvcs. It really doesn't matter that distributed model is better than centralized, some people will not switch over. And svn is great choice for them.

edabobojr 16y ago

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.

jarin 16y ago
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.
jevinskie 16y ago
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!
- edabobojr 16y ago
  Whenever people talk about git, they seem to talk about how you can have all of these working copies locally. My concern is the frequency with which code would be published to the centralized server and possible loss if all of the working copies were to disappear. Admittedly, this is a bigger problem in svn if you aren't using branches for work-in-progress.
dspillett 16y ago
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 work out too inconvenient as it can do with larger teams) meaning we could see what files he had checked out. And sometimes he'd just edit local copies of files without checking them out/in at all, and often "lost" updates somehow (usually, I think, accidentally overwriting them with the source controlled versions he'd not updated). <Deity> alone knows how much confusion he could have caused with his own local repository. He might have worked for weeks without pushing to elsewhere then lose the whole local repo. Then again I usually felt safer if his work wasn't in source control anyway. I often thought it might be quicker to stay late and do the work myself from the start instead of staying late fixing his work as often as I needed to...

binarysoul 16y ago

a simpler solution, use git-svn

jarin 16y ago
Any time I take on a client project that uses SVN, I always use git-svn. Once you get used to working with git-flow and feature branches, you never go back.

mcantor 16y ago

> 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 you commit the binary file and changes to smaller text files in the same changeset? If so, you should be committing them separately. Either you're making small commits to text files that commit almost instantly, or you're making large commits to binary files that you can't "pick out" changes from anyway. Gotta pick one.) > As soon as the commit is published, other people may check it out and try building it... > ... if I can't access the repository server – if it's gone down, or if I'm working remotely – then I can't commit at all. > ... but there are many reports [weasel words] of it being somewhat prone to error. If your mergeinfo property has been corrupted somehow, it might be extremely hard to spot... I see a lot of inconclusive beating around the bush here. The author doesn't want to come out and say that any of these are concrete showstoppers because they are all, at worst, edge cases that experienced svn users mostly know how to deal with anyway. Every VCS has its own bugbears like these, git included. I have been using subversion for years; I do all kinds of insane nonsense with private branches, merging and merge-tracking, large asset commits and all of the things this article uses for its doomsaying. I run into big problems maybe two or three times a year. The writer suggests that git is better. For some reason, even though I have read numerous manuals and guides about git, and have grilled git experts, and have regularly used git myself, and presumably understand how it works, I have to go on a farcical journey into its implementation details every time I do ANYTHING. I always end up in #git, or calling a more git-savvy friend. Everyone inevitably has a different answer that involves a lot of shrugging and "Oh, I guess this actually happened." This was the result even when all I did was follow the instructions at help.github.com/forking, TO THE LETTER. Perhaps I am just a moron, and subversion is just VCS for morons. If so, I am too far gone to realize.

mortice 16y ago
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.

glenjamin 16y ago

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.

jmillikin 16y ago
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".
- glenjamin 16y ago
  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?