Re: [boost] Why I hate subversion

From: Brian Davis (bitminer_at_[hidden])
Date: 2008-07-31 17:05:07

>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.  With only one lost
day consider yourself lucky.  SVN corruption is just a matter of time.

I am curious on any issues experienced with subversion.  These are issues I
have experienced (believe me there are others):

1) SVN cannot manage it's own internal state

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

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.
b) attempts to change the diff and diff3 commmands in .subversion/config
with my own versions have met with limited results.

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.  This leaves user
wanting cvs get-clean-copy command in svn or simply a better version control
tool.

use case:
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.  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.

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

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 Merge
Tracking"<http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword>

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

The major difference with GIT, Mercurial, and others is that they are
distributed version control tools allowing multiple repositories.  SVN and
CVS are centralized.  With GIT you can always commit your current changes
locally without having to update from a central repository something that
centralized version control tools do not provide.  With SVN all H#}} can
break lose when you update before a commit.  Now people will say that this
is what branching and merging is for in SVN and if it worked I would agree
with them, but in my opinion it is sadly broken and I truly had high hope
for this working.  It is only when you wish to merge those changes back to
the central repo with GIT that you pay the penalty of merging.  With GIT you
can commit locally and then commit remotely (thus making tarnosvn not
necessary as you can always commit local changes locally).  Your file system
is not smattered with .svn or .cvs directories as it is all kept in the .git
directory (top level 1 separate directory).  There are other reasons, but I
will digress.

http://www.selenic.com/mercurial/wiki/
http://git.or.cz/

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

-- 
Brian