5 ms·

While many responses are going to be "yawn", especially in the face of the git juggernaut, a great many enterprise systems are locked into svn for the foreseeab

by sgharms 18y ago

While many responses are going to be "yawn", especially in the face of the git juggernaut, a great many enterprise systems are locked into svn for the foreseeable future (given economic forecasts, IT departments aren't getting tons of budget for SCM migration / upgrade). Therefore a few extra features coming in are welcome...even if they don't begin with git-

st3fan 18y ago
great many enterprise systems - oh please give me a break. Subversion has nothing to do with enterprise blah. Many of us simply use svn because it is a fine tool and gets the job done. For all kinds of projects, from open source to 'enterprise'. Seriously .. don't put the enterprisey stigma on it. It does not deserve that.
- jrockway 18y ago
  Subversion... the version control system of choice for people that don't understand version control.
  - axod 18y ago
    Please feel free to educate us. I use version control and have done for years. I don't branch or merge, and svn works brilliantly for me. It stays completely out the way and allows me to rollback, see changesets, logs, etc if I need. If I wrote a version control system based on my own use case, it'd end up pretty much like svn. What am I missing? I've read all the "Git is AWESOME" posts. If I switched to git, it would be exactly the same. It wouldn't solve any problem for my use case that svn doesn't. Seriously unimpressed with your comment to be honest. Either make a valid argument as to what I don't understand about version control, or retract it.
    - trapper 18y ago
      But, but it's cool to love git!
    - jrockway 18y ago
      How do you un-"svn update" after you don't like its auto-merge? (Unless you never use svn update, you do branch and merge. You just don't have any control over how it works.)
      - ankhmoop 18y ago
        Two developers working on the same files at the same time is a suboptimal arrangement, and should it arise, actual communication outside of the VCS is necessary. Git automates patchset management, not merging of rapidly diverging branches of the -same- code. With or without git, independent developers working on a set of patches for the same code will introduce genuine implementation conflicts that can not be merged without independent communication. If, however, you should find yourself in this remarkably inefficient situation (ie, a commit war over simultaneously modified files), I recommend: 1) Speak to the other developer. 2) svn diff >saved.diff && svn up OR tar -cf ../svn.bak.tar . && svn up
      - axod 18y ago
        I've never needed to do that. The auto-merge has never failed for me. Give me an example of when you "wouldn't like its auto-merge".
        jrockway 18y ago
        All the time? Sometimes I am working on Bar, and want to update Foo. Unfortuantely, someone changed Bar, and now I have to deal with that change right now no matter what. And, I don't get the opprotunity to decide if I want the change to Bar; svn just auto-merges the changes in. There is nothing I can do to stop that, and no way to revert the change once it's happened. (In git, you can roll-back to any committed state. In svn, you can't even commit if there is a conflict.) Anyway, I am glad you like svn. But it is probably due to some reason other than svn's technical merits like, "at least it doesn't have all these Ruby fanbois." That is totally understandable, ignornat fanboi-ing is VERY off-putting. (To be fair, I started using Git loooong before it was popular. So I don't consider myself a fanboi.) Also, you don't learn anything new by sticking with what you already know. Perhaps it is worth expanding your horizions. Maybe try creating a branch in svn and go from there -- you might like it.
    - seanb 18y ago
      I mostly agree, but have been using git almost exclusively lately. The big draw for me is the ability to (easily) commit locally (and roll back those commits if I mess something up), then push commits to the "master" repository selectively. If SVN allowed for a similar workflow, it would satisfy my needs just fine. Of course, any distributed VCS would probably fit that description... I found mercurial to be nice as well, and I used it happily for a couple projects. The primary reason for switching to git was to become familiar with another tool.
      - axod 18y ago
        Just install a local svn repository :/
        seanb 18y ago
        An option perhaps, but "just install git" seems even easier.
- DTrejo 18y ago
  He did not put the "enterprisey stigma" on it. He only talked about how some enterprises are locked in, and appreciate updates. It appears you misread something.

by sgharms 18y ago

st3fan 18y ago

great many enterprise systems - oh please give me a break. Subversion has nothing to do with enterprise blah. Many of us simply use svn because it is a fine tool and gets the job done. For all kinds of projects, from open source to 'enterprise'. Seriously .. don't put the enterprisey stigma on it. It does not deserve that.

jrockway 18y ago
Subversion... the version control system of choice for people that don't understand version control.
- axod 18y ago
  Please feel free to educate us. I use version control and have done for years. I don't branch or merge, and svn works brilliantly for me. It stays completely out the way and allows me to rollback, see changesets, logs, etc if I need. If I wrote a version control system based on my own use case, it'd end up pretty much like svn. What am I missing? I've read all the "Git is AWESOME" posts. If I switched to git, it would be exactly the same. It wouldn't solve any problem for my use case that svn doesn't. Seriously unimpressed with your comment to be honest. Either make a valid argument as to what I don't understand about version control, or retract it.
  - trapper 18y ago
    But, but it's cool to love git!
  - jrockway 18y ago
    How do you un-"svn update" after you don't like its auto-merge? (Unless you never use svn update, you do branch and merge. You just don't have any control over how it works.)
    - ankhmoop 18y ago
      Two developers working on the same files at the same time is a suboptimal arrangement, and should it arise, actual communication outside of the VCS is necessary. Git automates patchset management, not merging of rapidly diverging branches of the -same- code. With or without git, independent developers working on a set of patches for the same code will introduce genuine implementation conflicts that can not be merged without independent communication. If, however, you should find yourself in this remarkably inefficient situation (ie, a commit war over simultaneously modified files), I recommend: 1) Speak to the other developer. 2) svn diff >saved.diff && svn up OR tar -cf ../svn.bak.tar . && svn up
    - axod 18y ago
      I've never needed to do that. The auto-merge has never failed for me. Give me an example of when you "wouldn't like its auto-merge".
      - jrockway 18y ago
        All the time? Sometimes I am working on Bar, and want to update Foo. Unfortuantely, someone changed Bar, and now I have to deal with that change right now no matter what. And, I don't get the opprotunity to decide if I want the change to Bar; svn just auto-merges the changes in. There is nothing I can do to stop that, and no way to revert the change once it's happened. (In git, you can roll-back to any committed state. In svn, you can't even commit if there is a conflict.) Anyway, I am glad you like svn. But it is probably due to some reason other than svn's technical merits like, "at least it doesn't have all these Ruby fanbois." That is totally understandable, ignornat fanboi-ing is VERY off-putting. (To be fair, I started using Git loooong before it was popular. So I don't consider myself a fanboi.) Also, you don't learn anything new by sticking with what you already know. Perhaps it is worth expanding your horizions. Maybe try creating a branch in svn and go from there -- you might like it.
  - seanb 18y ago
    I mostly agree, but have been using git almost exclusively lately. The big draw for me is the ability to (easily) commit locally (and roll back those commits if I mess something up), then push commits to the "master" repository selectively. If SVN allowed for a similar workflow, it would satisfy my needs just fine. Of course, any distributed VCS would probably fit that description... I found mercurial to be nice as well, and I used it happily for a couple projects. The primary reason for switching to git was to become familiar with another tool.
    - axod 18y ago
      Just install a local svn repository :/
      - seanb 18y ago
        An option perhaps, but "just install git" seems even easier.
DTrejo 18y ago
He did not put the "enterprisey stigma" on it. He only talked about how some enterprises are locked in, and appreciate updates. It appears you misread something.