I've been off this list for some time, so my appologies if
it has been mentioned already.
I am using subversion 1.1.4 and TortoiseSVN 1.1.3(and also
I found a fuzzy behaviour which may be a bug in subversion
or TortoiseSVN. I couldn't conclude on which to blame,
since I couldn't find the concrete API definition for the
If a .svn/entries file have a repository URL that has RAW
(as opposed to %-escaped) utf-8 characters within it, a
commit of a file does not update the revision number that
appears in the files in .svn/wcprops/* .
This results in a succeeding commit of the same file to
fail with out-of-date error. Performing update on the file
or its parent directories does not resolve this matter,
but brute forcing with an editor and hand correct the
revision number in .svn/wcprops/* file does resolve the
issue (for this one time).
Obviously, this is a problem in the state of checked out WC,
so deleting this WC and checking out a fresh one will allow
me to commit again (but again only once, if you checkout
with TortoiseSVN; see below).
Other random things that I noticed:
O wcprops/* and dir-wcprops are seemingly not used for
file:// and svn:// repositories. So only WC's that are
checked out from https:// (and http:// ?) repositories are
(Thus I couldn't come here with a simple sample transcript... :( )
O subversion-1.1.4 %-escapes all non-ASCII chars that were
given on the command line at the time of check out, as
well as the non-ASCII chars in subdirectory names under
the checked-out root, where as TortoiseSVN leaves the
repository part raw, and only escapes the subdirectory
part. Therefore, a WC checked out by TortoiseSVN has the
above mentioned problem for commits performed by either
subvesrion or TortoiseSVN, whereas a WC checked out by
subversion are handled correctly by both subverson AND
O subversion as well as TortoiseSVN do not %-escape the
name="..." part in the .svn/entries file, and the first
line of this file says encoding="utf-8", so the use of
utf-8 itself did not look as to be forbidden in this file.
O If multiple WC are checked out from the same repository,
and many concurrent commits and updates occur, chances are
that wcporps/* will be updated in the course of fetching
other people's work, and above mentioned problem will not
be observed so much; it took me some months to come up
with the above reproducible description.
Now to the final part:
Should subversion be more gracefull and process the raw
utf-8 url correctly, or should TortoiseSVN be more strict
and always %-escape every non-ASCII chars?
If former, will it be fixed in 1.1 branch?
If latter, I will try the TortoiseSVN list next. In this
case, I'd appreciate a pointer to some documentation that
should convince TortoiseSVN developers.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu May 12 13:08:04 2005