Boost logo

Boost :

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

> 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
> Why should I have to use the syntax:
> svn log --verbose --stop-on-copy \
> 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
> Why not:
> svn merge -r ROOT:HEAD
> 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
> Merge tracking (foundational)
> <>
>"The Final Word on MergeTracking"

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

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.



Boost list run by bdawes at, gregod at, cpdaniel at, john at