[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

dump / verify stumbles over double slashes "//"?

From: Lutz Dornbusch <svn_at_yogasurftech.de>
Date: Mon, 30 Jun 2008 15:05:44 +0200

Hello
I recently coded a small java application based on svnkit which performs
some copyactions (directly on server via file://)inside a single
transaction: eg.
folder_1/file_a -> folder_100/file_a
folder_1/file_b -> folder_100/file_b
folder_2/file_c -> folder_101/file_c

I had a small bug in my program which adds an additional slash "/" to
each folder, so the above mentioned sample reads:
folder_1//file_a -> folder_100//file_a
folder_1//file_b -> folder_100//file_b
folder_2//file_c -> folder_101//file_c

However, the commit runs fine and I was also able to update a
workingcopy, so I didn't bother about this double slash. But if I try to
verify my repository or dump its contents I run into terrible problems:
The Revision I produced by my java app breaks the repository. Verify and
dump will both stop on the same revision with this message:

Assertion failed: is_canonical(component, clen), file
C:\Projects\subversion-1.4
.6\subversion\libsvn_subr\path.c, line 115

I think this a bug of svn, as it really should not allow to commit
"non-canonical paths" if it is not able to handle them. By using a
customized client (my java app, in this case) I am able to destroy a
repository so it can not be verified anymore or be backuped, but you can
still work with this repository.

Should I file an issue? can somebody confirm this behaviour?

I am using svn 1.4.6

Thanx for your time,
Lutz Dornbusch

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-07-01 16:10:53 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.