Eric Niebler wrote:

No misuse, and no tool other than subversion. FWIW, I'm running subversion via cygwin on vista. Is this just the price of doing business on windows?

"Permission denied!" More subversion corruption. Another day lost.

Try using the native win32 subversion binaries instead. I've seen similar problems with the Cygwin version on Windows XP, as has a colleague of mine, especially when we were using svn from inside cygwin bash scripts or 'find' operations. The problems disappeared when we switched to using the native binaries.

Eric Niebler wrote:

Timo Geusch wrote:

...

Eric Niebler wrote:

...

"Permission denied!" More subversion corruption. Another day lost.

Try using the native win32 subversion binaries instead. I've seen similar problems with the Cygwin version on Windows XP, as has a colleague of mine, especially when we were using svn from inside cygwin bash scripts or 'find' operations. The problems disappeared when we switched to using the native binaries.

Ah, thanks for the tip. I'll try that.

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. -- Eric Niebler BoostPro Computing http://www.boostpro.com

On Jul 31, 2008, at 5:05 PM, Brian Davis wrote:

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.

Boost will not consider another source code management tool without a complete plan for hosting the Boost repository, including details regarding who administers the server, where that server is located, whether it can handle our bandwidth requirements, etc, along with a plan for migrating all of Boost's tools and processes on all platforms to this new system. Without a comprehensive plan, any discussions of alternative source code management systems for Boost are merely noise on this mailing list, and distract us from what we do best: build great libraries for the C++ community. - Doug

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

Eric Niebler <eric <at> boost-consulting.com> writes:

No misuse, and no tool other than subversion. FWIW, I'm running subversion via cygwin on vista. Is this just the price of doing business on windows?

"Permission denied!" More subversion corruption. Another day lost.

I use Windows XP as my primary development platform, and subversion works fine. However, I don't use cygwin (I prefer native ports of unix apps --- gnuwin32.sf.net has quite a selection, and I found a port of tcsh and other tools too), and I don't use Vista, so it might be either of those to blame. The only times I've had subversion repository corruption were: 1. I had a large disk (160Gb), without all the "large disk" flags ticked in Windows, so when the data expanded over 128Gb, it was mapped onto data at the beginning of the disk. This initially appeared as occasional bad files in the subversion repository and elsewhere, and eventually resulted in a trashed disk. 2. Someone checked in a symlink on linux. This is disastrous for a Windows sandbox. You can't check it out, you can't delete it, you can't clean up the sandbox once it's there .... you have to delete it from the repository, and then recreate the sandbox. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL