7 ms·

Subversion 1.6 released.

43 points by jawngee 18y ago

visitor4rmindia 18y ago
>Subversion 1.6 recognizes a new kind of conflict, known as a "tree conflict". Such conflicts manifest at the level of directory structure, rather than file content. >Situations now flagged as conflicts include deletions of locally modified files, and incoming edits to locally deleted files. Files and directories which are victims of a tree conflict cannot be committed before the conflict is marked resolved. Wow - finally! This is great. We've had to handle these edge cases during merges (greatly slowing our scripts) for a long time. Hopefully this will give us significant speed improvements which should help with one of the minor irritants of our users.
- newt0311 18y ago
  SVN is basically developing the graph structure that other DVCSs have had ever since their inception (because a DVCS is toast without one and svn can manage).
graywh 18y ago
<sarcasm> Hackers were still using svn and not a dvcs? </sarcasm>
hypermatt 18y ago
yawn
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
vinutheraj 18y ago
Here's a scenario - there are 2 coders working on basically the same base code, but each doing something different. Now the code from both these guys needs to be merged to the base code periodically, so what do you think these guys should use - git or svn , or any other VCS for that matter ?
- visitor4rmindia 18y ago
  I suppose any good VCS should work fine. Each dev should get his/her own branch which is periodically merged upstream. We use SVN and it does the job just fine. In fact, we are still stuck on 1.4 so we track merges ourselves which isn't really a big deal.
jhawk28 18y ago
I wonder if the CTypes Python bindings will help out the DVCS clients such as Bazaar or Mercurial. Bazaar already has good client support for SVN. It would be nice if Mercurial would get first class support.
- durin42 18y ago
  Not really. I've looked at the ctypes bindings (I've got a set of incomplete patches to them), and they lack diff and replay support, which makes them basically useless for building a client. Git uses the perl bindings, so I can't speak to the quality of those. Bazaar uses a library called subvertpy that they wrote when they got tired of the suck and pain that is the Python SWIG bindings for Subversion. I'm about to switch to using that for hgsubversion, since fixing up the ctypes bindings has proven to be nothing more than a monumental pain.
  - jhawk28 18y ago
    That would be awesome. I prefer using Mercurial to Bazaar, but I really need the subversion client interface.
njoubert 18y ago
After updating my svn client on my mac and my ubuntu box to this, eclipse no longer manages to do anything with the team features....

43 points by jawngee 18y ago

>Subversion 1.6 recognizes a new kind of conflict, known as a "tree conflict". Such conflicts manifest at the level of directory structure, rather than file content. >Situations now flagged as conflicts include deletions of locally modified files, and incoming edits to locally deleted files. Files and directories which are victims of a tree conflict cannot be committed before the conflict is marked resolved. Wow - finally! This is great. We've had to handle these edge cases during merges (greatly slowing our scripts) for a long time. Hopefully this will give us significant speed improvements which should help with one of the minor irritants of our users.

newt0311 18y ago
SVN is basically developing the graph structure that other DVCSs have had ever since their inception (because a DVCS is toast without one and svn can manage).

graywh 18y ago

<sarcasm> Hackers were still using svn and not a dvcs? </sarcasm>

hypermatt 18y ago

yawn

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

vinutheraj 18y ago

Here's a scenario - there are 2 coders working on basically the same base code, but each doing something different. Now the code from both these guys needs to be merged to the base code periodically, so what do you think these guys should use - git or svn , or any other VCS for that matter ?

visitor4rmindia 18y ago
I suppose any good VCS should work fine. Each dev should get his/her own branch which is periodically merged upstream. We use SVN and it does the job just fine. In fact, we are still stuck on 1.4 so we track merges ourselves which isn't really a big deal.

jhawk28 18y ago

I wonder if the CTypes Python bindings will help out the DVCS clients such as Bazaar or Mercurial. Bazaar already has good client support for SVN. It would be nice if Mercurial would get first class support.

durin42 18y ago
Not really. I've looked at the ctypes bindings (I've got a set of incomplete patches to them), and they lack diff and replay support, which makes them basically useless for building a client. Git uses the perl bindings, so I can't speak to the quality of those. Bazaar uses a library called subvertpy that they wrote when they got tired of the suck and pain that is the Python SWIG bindings for Subversion. I'm about to switch to using that for hgsubversion, since fixing up the ctypes bindings has proven to be nothing more than a monumental pain.
- jhawk28 18y ago
  That would be awesome. I prefer using Mercurial to Bazaar, but I really need the subversion client interface.

njoubert 18y ago

After updating my svn client on my mac and my ubuntu box to this, eclipse no longer manages to do anything with the team features....