Re: [boost] Why I hate subversion

From: Ulrich Eckhardt (doomster_at_[hidden])
Date: 2008-08-02 13:18:16

On Thursday 31 July 2008 23:05:07 Brian Davis wrote:
> >Update: it's been 4 months and I've experienced no subversion corruption.
>
> Moral: don't use cygwin's subversion client on windows; use the native
> win32 client instead.
>
> Moral of the story: Switch to a better Source Control Management Tool.  I
> have experienced issues in both Linux (both command line, rapid, and
> eclipse svn plugin subeclipse), cygwin (command line), and Win32 (native
> using only TortoiseSVN).  I have experienced issues in all three. 

I have been using SVN since before it was released and without any issues that 
couldn't have been avoided or that couldn't have been resolved easily.

> With only one lost day consider yourself lucky.  SVN corruption is just a
> matter of time.

RTFM, I dare say. Maybe having some understanding of what is going on behind 
the scenes is also a good idea. I mention that because knowing some design 
decisions that were made helps you understand how SVN works and why it works 
exactly that way.

> use case:
> a) change a file locally and try to move it then check it in. <- will fail
> b) move a file locally, change it then check it in. <- will succeed

I don't think so, can you provide precise steps to reproduce that? I remember 
just yesterday copying a dir with changes between two unrelated working 
copies and I haven't found any problems there.

> 2) Merges of entire branch produce interesting results especially on mixed
> platform development Win32/Linux
>
> a) line ending diffrences and other white space cause files to show
> diffrences when there are none leaving the developer to manually merge
> files which are not different with Right Hand Side containing copy of Left
> Hand Side + same text as User copy.

This indeed is a problem, though I found that it is usually caused by misuse, 
i.e. that the line-ending style wasn't set. This results in some tools 
enforcing their preferred line ending and since diffs typically ignore them, 
developers then check in files which have all their line endings changed. As 
I said, this is a user failure in my eyes, SVN's default behaviour of exactly 
retaining the content of a file is correct.

> b) attempts to change the diff and diff3 commmands in .subversion/config
> with my own versions have met with limited results.

Have you taken that to the SVN users' mailinglist?

> 3) Developer has to periodically result to tar no svn directories (tarnosvn
> - a script I had to write explicitly for this purpose) directories when the
> tree cannot be checked out due to now missing directories on remote branch
> as though SVN cannot figure out that the user branch and remote branch
> contain directories that have been removed or deleted.

Are you even aware of the fact that SVN only versions directories and is of 
itself completely unaware of what _you_ think constitutes a branch? In 
particular, what are user branches and remote branches? I'm sorry, but I have 
the growing feeling that you aren't sufficiently familiar with the tool you 
are complaining about.

> This leaves user wanting cvs get-clean-copy command in svn or simply a
> better version control tool.

Looked at 'svn export' yet, perhaps with BASE as revision? I'm not sure 
what 'get-clean-copy' is, I couldn't find that documented...

> a) Developer A (identities changed to protect the innocent) moved or
> deletes a subtree (using subtree with in the tree so as not to confuse with
> branch of a repository) from the tree.
> b) Developer B all excited to check in new changes attempts to update
> current tree to head of integ only to find gobs of errors in directories
> that have been moved or deleted.

Of course, changing something conflicts with deleting the same files, so why 
would you want anything less than an error? What would you want to commit 
your changes to, after all your target for the modifications has been 
deleted!

> Developer tries in vein to delete said directories and recursive calls to
> svn update and svn cleanup and finally results to taring up source code in
> tree, deleting tree, and getting clean copy.

I understand your troubles, but I'm pretty sure that they are caused by not 
knowing the tool or, worse, making false assumptions how it's supposed to 
work and trying fix something using wild guesses how to do that.

> Merging commands are not intuitive:
>
> See
> http://svnbook.red-bean.com/en/1.0/ch04s04.html
>
> Why should I have to use the syntax:
>
> svn log --verbose --stop-on-copy \
>           http://svn.example.com/repos/calc/branches/my-calc-branch
>
> I am told by developers that this is perfectly legitimate and makes perfect
> since.  Processes of convolution never "make sense" to me especially for
> common use cases.  If I need to know the root of the branch that I have
> check out why not suport this with a syntax that is reasonable like:
>
> Instead of:
>
> svn merge -r 341:HEAD
> http://svn.example.com/repos/calc/branches/my-calc-branch
>
> Why not:
>
> svn merge -r ROOT:HEAD
> http://svn.example.com/repos/calc/branches/my-calc-branch
>
> Where ROOT is the root of my branch and SVN "figures out" r341

Please read the Subversion book again. SVN primarily only versions a directory 
tree. The separation in trunk/tags/branches is just a suggestion how to 
organise things, but SVN itself is completely unaware of the meanings that 
are associated with those directories. Now, since a branch is just a copy 
from one location to the other, SVN can't tell it apart from a copy operation 
that took place inside the branch which is part of the normal changes there. 
How then should it figure out which one should be taken to generate ROOT in 
your example?

Note that this is not something that is actually impossible to figure out, but 
it requires some work and some annotations to the meaning of a copy operation 
(I think).

> Some issues may be fixed in 1.5:
> Improvements to copy and move
><http://subversion.tigris.org/svn_1.5_releasenotes.html#copy-move-improvements>
> Merge tracking (foundational)
> <http://subversion.tigris.org/svn_1.5_releasenotes.html#merge-tracking>
>"The Final Word on MergeTracking"
><http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword>

Yes. After actually quite some time discussing how to do merge tracking and 
how to do it _right_, it was introduced in 1.5 which is supposed to ease 
branching and merging a lot.

> Has any one investigated GIT.  I think I am in the Linus on this.... "with
> basis that SVN is a better CVS... there is no where to go form there".
> Though I do not condone how he makes his point / his approach.  The only
> way for SVN to be a better Configuration Management tool to to break it's
> ties with CVS, and in my opinion go distributed.
>
> Linus speaks to Google about GIT
> http://www.youtube.com/watch?v=4XpnKHJAok8

I haven't looked at this, but I think I know the video. IMHO Linus makes a 
very important point there, that the usefulness of a version control system 
is how good it is at branching and merging, which has improved a lot in SVN 
1.5. Another important difference is the distributed vs central system. If 
you are actually disconnected from the web, a distributed system has its 
advantages, otherwise just making a branch to which only you commit and which 
is then merged back to the trunk works equally well, except that others can 
see your work, too.

> I know I will never find a perfect tool, I am just on a search for the one
> that is least hateful.

I'll help you to get around the quirks in SVN, which exist without doubt. I'm 
confident that you can get along with it and that it is not so bad that it 
must be replaced.

regards

Uli