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

Re: svn assertion

From: Carlo Kok <ck_at_carlo-kok.com>
Date: 2006-01-29 23:37:56 CET

kfogel@collab.net wrote:
> Carlo Kok <ck@carlo-kok.com> writes:
>> I have an older checkout done by rapidsvn that has entries with urls
>> like:
>> url="svn://buurtnet/projects/trunk/" ;
>> svn 1.3 seems to give runtime assertions when I execute:
>> svn status -Nu
>> in such a directory.
>> Assertion failed: is_canonical (base, blen), file
>> C:\Home\brane\src\svn\releases\subversion-1.3.0\subversion\libsvn_subr\path.c,
>> line 114
>> Having to fix this in each and every directory is quite a hassle, would
>> it be possible for SVN to just accept this and strip of the ending slash?
> I'm a little leery of having SVN silently clean up bad data in the
> working copy administrative area. Not that this data is fatally bad,
> but it's not something SVN would have written, and presumably modern
> versions of RapidSVN wouldn't write it either. The working copy
> metadata is pretty sacred stuff; better to be strict than loose about
> it, that way we can detect it when tools start to stray.

Actually it's RapidSVN 0.9 which uses SVN 1.2.3 that I managed to check
this out with (I used svn://buurtnet/projects/trunk/ as an url, not
knowing that that could cause harm). That's the newest RapidSVN
available and isn't that old. Although I agree it's easy to fix myself,
I just wanted to report this.

> Fixing it by hand shouldn't be such a big hassle. (By the way, that
> semicolon isn't really there, right?)

Nope it's not really there.

Carlo Kok
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jan 29 23:38:18 2006

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.