Hi
Speaking as a relatively new user to Subversion (a couple of months), the
most confusing errors are the "not locked" variety.
In my experience (apart from the horrors of disconnected working copies
caused by direct repository moves), the "not locked" errors are the most
inexplicable:
1. you don't know what you've done to cause the error
2. The error message is totally obscure (from a user's perspective)
Naïve reaction to message after reading the SVN intro:
"I thought Subversion didn't rely on locking ..."
3. You have absolutely no idea how to fix it
(or avoid it happening in the future).
My usual fix is to delete the working copy and check it out again. Until
these errors either go away or make it clear how to avoid/recover, I'm
letting colleagues continue on with CVS.
Don't get me wrong - I really like Subversion, and don't ever want to go
back to CVS, but for those new to version control, these sort of errors give
an "unstable feel" to the system - not good for "spreading the word" :-)
It really helped when I read "Nothing is more important than your data"
somewhere on the subversion site/book. This has make me more confident about
deleting working copies and checking out again (but it still feels wrong to
have to do this) ...
Maybe all that's needed (at least in the short term) are error messages that
help you recover or know what NOT to do next time ...
From a user's perspective, if the patch reduces error messages and doesn't
damage anything, I'm all for it :-)
My thoughts, and many thanks to those putting in the hours
Giovanni
> -----Original Message-----
> From: Ross Mark [mailto:rossm@controllingedge.com.au]
> Sent: Tuesday, 18 May 2004 5:32 p.m.
> To: dev@subversion.tigris.org
> Subject: Re: [PATCH] fix "not locked" error message when
> updating an externals entry with multiple directories.
>
>
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 18 08:56:36 2004