
Subversion 1.6 released. - jawngee
http://subversion.tigris.org/servlets/NewsItemView?newsItemID=2261
======
visitor4rmindia
>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.

------
sgharms
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
_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
Subversion... the version control system of choice for people that don't
understand version control.

~~~
axod
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.

~~~
jrockway
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.)

~~~
axod
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
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.

~~~
axod
For me, it's like trying to persuade me to use ReiserFS, rather than ext3. I
just don't care unless it's performing badly.

Why can't you just "svn update Foo" ? Then you don't have to deal with the
changes to Bar :/ I don't really see what the issue is. Are you often working
on exactly the same files as other developers, and not co-ordinating what
you're doing?

>> "Anyway, I am glad you like svn. But it is probably due to some reason
other than svn's technical merits..."

I like it, because it solves my use case perfectly. I'm not quite sure you
understand that.

I'm not one of these people that love technical solutions for the sake of
being technical.

~~~
jrockway
You also seem to be intentionally closed-minded, for the purpose of gaining
karma on social news sites. I think that's sad, but I realize that it's your
loss, not mine.

~~~
axod
I care not a jot about karma. What I do care about is ill informed people
spouting rubbish.

You stated that anyone using subversion must not understand revision control.
Which is an idiotic comment.

I detest this pompous high and mighty tools based attitude. Does anyone not
using lisp not understand programming? Anyone not using ruby on rails not
understand how to build webapps?

I'm actually very open minded. When I have problems with subversion, I'll
likely try git if it fits my use case at the time. At the moment, it doesn't.

~~~
jrockway
_You stated that anyone using subversion must not understand revision control.
Which is an idiotic comment._

But you said above that you don't want to understand version control; you said
you just want to use it. This does not disprove my statement.

------
vinutheraj
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
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
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
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
That would be awesome. I prefer using Mercurial to Bazaar, but I really need
the subversion client interface.

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

------
hypermatt
_yawn_

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

