Its been over a week now with no comments about this patch so I thought
I better raise the issue again just in case people wanted to discuss
whether this is actually a bug or not.
This issue is a major annoyance if you use svn:externals for version
control. That is you change the svn:externals entry to point to an
explicit tag which gets updated for explicit releases.
In case people don't understand what the problem is I'll go over it in a
little more detail.
Say you have two repositories with the following structure:
rep1/trunk/foo/bar
/tags/1/foo/bar
/2/foo/bar
A simple layout with two versions of foo/bar tagged.
In a separate repository there is an svn:externals entry like
"remote file://rep1/tags/1"
Now when the svn:externals entry is changed to
"remote file://rep1/tags/2"
an svn update will fail with "svn: Working copy 'remote/foo' not locked"
because the svn does a non-recursive lock on the current directory prior
to deletion but the deletion errors because the subdirectory is not locked.
The original patch email had a script that demonstrated this problem
which I can resend if needed.
The current work around is to realise where the error occurred, look as
the svn:externals to get the url and then do a svn switch within the
subdirectory to bring it uptodate.
My patch was just to make the lock request recursive so the external
directory can be deleted. On the 1.0.x tree this means changing the
subversion/libsvn_client/externals.c relegate_external() the
svn_wc_adm_open should have a TRUE rather than a FALSE for recursive
locking, or in the trunk the svn_wc_adm_open2 should have a depth of -1.
The test case for externals only uses a directory with files in it as
the test case. If it were to add a subdirectory this error would have
been detected.
I also have another patch that tries to do an "svn switch" internally
when the url of the svn:external doesn't match the working copy. If the
switch fails it falls back to doing a relegate_external call. In most
this is far more efficient than the default behavior of a delete and
checkout again. I thought I better wait to see the results of this patch
which is small and simple before submitting the slightly more complex one.
Ross
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 18 07:32:39 2004