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