Bugs I managed to run across in the last hour / hour and a half of fiddling
with the intent to confuse the client (but limiting myself to relative
paths, as I doubt absolutes have that much of a hope, and not using ra_dav,
as the boundary cases with URL's vs. Win32 paths aren't coming to me at the
moment... need food):
- svn_cl__edit_externally does not init *edited_contents to NULL
- / vs. \ directory splitting
- file canonicalization for / vs. \ and '.'
- cross directory copies on deleted files causes mass confusion
- Case SeNsitiVity
- out-of-date transaction sillyness
All of these are bugs that cause the working copy to be FUBAR'd until you
manually go and start editing admin files to clear up the situation (which I
consider more than a slight annoyance, or whatever it was that Brane was
harping about as a low priority complaint). Some of them are probably not
Win32 specific, two -- maybe even three -- of them might be covered by issue
#603 (although #603 makes it sound as if the problem normally doesn't come
up except in this one extreme case that is mentioned from the mailing
list... I used to run into this every few days when I would forget the
stringent rules on how to format my command line arguments... trashed a ton
of working copies).
I have some leads on a few more, but I have to run. Maybe tomorrow.
Regardless, am _quite_ impressed with how the problem of directory moves and
deletes was dealt with on Win32. My great thanks to whomever was working on
that (assuming Brane as he snapped back that he had fixed that).
=======================
svn_cl__edit_externally does not init *edited_contents to NULL
Many of the weirder crash bugs that have come up in the past crop up due to
fortuitous usage of existing memory... luckily, VC++ helps us here :).
Anything you allocate a pointer, you should seriously consider whether or
not you need to set it to NULL.
The call:
const char *msg2; /* ### shim */
err = svn_cl__edit_externally (&msg2, lmb->base_dir,
tmp_message->data, pool);
if (msg2)
{
message = svn_stringbuf_create (msg2, pool);
}
fails to take into consideration that svn_cl__edit_externally() fails to
initialize the passed in pointer to NULL if an error is returned. The code
should either check for an error condition, or the function should set the
pointer to NULL. Either way, this crashes if you call use svn to commit
something without a -m argument and the editor isn't configured.
=======================
/ vs. \ directory splitting
When passing a path that contains a \ to the command line client, sometimes
it fails to split it into the various directory components. It realizes
that the file exists on disk, but files it as "a\b" in the parent of a,
rather than "b" in "a". Here is a transcript:
D:\Code\Ark>svnadmin create test
D:\Code\Ark>svn co file:///code/ark/test -d repos
Checked out revision 0.
D:\Code\Ark>cd repos
D:\Code\Ark\repos>svn mkdir a
A a
D:\Code\Ark\repos>svn commit -m "data"
Adding a
Committed revision 1.
D:\Code\Ark\repos>cd a
D:\Code\Ark\repos\a>touch file
D:\Code\Ark\repos\a>cd ..
D:\Code\Ark\repos>svn add a\file
WARNING: error fetching svn:mime-type property for a\file
D:\Code\Ark\repos>svn status
d:\code\ark\subversion\subversion\libsvn_subr\io.c:65
apr_error: #22503, src_err 0 : <The system cannot find the path specified.
>
svn_io_check_path: problem checking path "./.svn/props/a\file"
=======================
file canonicalization for / vs. \ and '.'
One would expect that \ would work as a file seperator a the command line,
but more often than not it doesn't. Before asking the file layer, things
tend to be converted, but before referencing the admin files, it often is
not. This is probably issue #603. The same thing occurs, more humourously
I might add, with a trailing "." (which is a useless character if listed at
the end of a file that has no extension).
D:\Code\Ark>svnadmin create test
D:\Code\Ark>svn co file:///code/ark/test -d repos
Checked out revision 0.
D:\Code\Ark>cd repos
D:\Code\Ark\repos>touch file
D:\Code\Ark\repos>svn add file.
A file.
D:\Code\Ark\repos>svn status
? ./file
A ./file.
--------------------------------------------
D:\Code\Ark>svnadmin create test
D:\Code\Ark>svn co file:///code/ark/test -d repos
Checked out revision 0.
D:\Code\Ark>cd repos
D:\Code\Ark\repos>svn mkdir a
A a
D:\Code\Ark\repos>svn mkdir b
A b
D:\Code\Ark\repos>svn commit -m "data"
Adding a
Adding b
Committed revision 1.
D:\Code\Ark\repos>cd a
D:\Code\Ark\repos\a>touch file
D:\Code\Ark\repos\a>svn add file
A file
D:\Code\Ark\repos\a>svn commit -m "data"
Adding a/file
Transmitting file data .
Committed revision 2.
D:\Code\Ark\repos\a>cd ..
D:\Code\Ark\repos>svn cp a\file b\file
d:\code\ark\subversion\subversion\libsvn_wc\copy.c:145
svn_error: #21012 : <Tried a versioning operation on an unversioned
resource>
Cannot copy or move 'a\file' -- it's not under revision control
=======================
cross directory copies on deleted files causes mass confusion
Not sure if this is a Win32 only issue, but when dealing with copies of
files between directories, things go batty. This used to actually get
farther than it does now. Continuing from the previous log:
D:\Code\Ark\repos>svn cp a/file b/file
A b/file
D:\Code\Ark\repos>cd a
D:\Code\Ark\repos\a>svn rm file
D file
D:\Code\Ark\repos\a>svn commit -m "data"
Deleting a/file
Committed revision 3.
D:\Code\Ark\repos\a>cd ..
D:\Code\Ark\repos>svn up
d:\code\ark\subversion\subversion\libsvn_fs\tree.c:177
svn_error: #21066 : <Filesystem has no item>
file not found: transaction `4', path `a/file'
=======================
caSe sEnsiTivity
Rather than resolving the file that is passed to the command line to
determine file case, file case is assumed to be equivilant to what the user
types. This causes situations such as having multiple versions of files on
the repository with different cases, continual attempts to update the
working copy due to the file name not matching, and possibly even duplicates
in admin file contents.
D:\Code\Ark>svnadmin create test
D:\Code\Ark>svn co file:///code/ark/test -d repos
Checked out revision 0.
D:\Code\Ark>cd repos
D:\Code\Ark\repos>touch file
D:\Code\Ark\repos>svn add File
A File
D:\Code\Ark\repos>svn commit -m "data"
Adding File
Transmitting file data .
Committed revision 1.
D:\Code\Ark\repos>svn status
? ./file
D:\Code\Ark\repos>svn up
Restored ./File
At revision 1.
D:\Code\Ark\repos>svn up
Restored ./File
At revision 1.
=======================
out-of-date transaction sillyness
I don't even understand what it's trying to do really
D:\Code\Ark>svnadmin create test
D:\Code\Ark>svn co file:///code/ark/test -d repos
Checked out revision 0.
D:\Code\Ark>cd repos
D:\Code\Ark\repos>svn mkdir bob
A bob
D:\Code\Ark\repos>svn commit -m data
Adding bob
Committed revision 1.
D:\Code\Ark\repos>cd bob
D:\Code\Ark\repos\bob>touch file
D:\Code\Ark\repos\bob>svn add file
A file
D:\Code\Ark\repos\bob>svn commit -m data
Adding bob/file
Transmitting file data .
Committed revision 2.
D:\Code\Ark\repos\bob>cd ..
D:\Code\Ark\repos>svn mv bob dork
A dork
D bob/file
D bob
D:\Code\Ark\repos>svn commit -m data
Deleting bob
d:\code\ark\subversion\subversion\libsvn_client\commit.c:585
svn_error: #21082 : <Transaction is out of date>
Commit failed (details follow):
d:\code\ark\subversion\subversion\libsvn_ra_local\commit_editor.c:112
svn_error: #21082 : <Transaction is out of date>
out of date: `bob' in txn `3'
D:\Code\Ark\repos>svn up
d:\code\ark\subversion\subversion\libsvn_wc\update_editor.c:609
svn_error: #21036 : <Obstructed update>
failed to add directory './bob': object of the same name already exists
Sincerely,
Jay Freeman (saurik)
saurik@saurik.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 6 03:16:20 2002