On Sun, Oct 17, 2004 at 12:32:23PM -0400, Greg Hudson wrote:
> If you hang around the #svn channel on IRC, you may observe that about
> half the time users use "svn switch --relocate", they specify the
> paths wrong and wind up having to ditch their working copies after
> receiving bizarre errors like "Working copy not locked." It's clear
> that our safeties on this command are inadequate.
Well, it might be safer to say that a large percentage of the time
that people have problems with --relocate, it's because they've used it
wrong. It's unlikely that users join #svn in order to report their
successes.
Second, --relocate is invertible (except in the case of mixed
repository WCs). It shouldn't be necessary to ditch a WC just because
of a misused --relocate. It is likely, though, that the kind of user
that misuses the functionality in the first place might not realize the
easy remedy.
I agree the problem incidence rate is unacceptably high
considering that it is possible for us to add additional safeties.
>
> It's also clear, at least to some developers, that "svn switch
> --relocate" doesn't have a lot in common with "svn switch" in
> operation, so it's not very natural that it's shoehorned into the
> switch command. Some people take this as an indication that relocate
> should be a separate command; I submit that "svn switch --relocate" is
> simply broken.
There was list discussion at the time that settled on the new option
rather than a new subcommand.
<discussion about automatically determining which operation is
happening removed after reading further>
>
> So, here is my three-phase grand unification scheme:
>
> PHASE 1: Collect repository roots
>
> Just as we store the uuid repository uuid in each .svn/entries
> entry, we should store the repository root as well. This way we can
> decompose the URL into repository-root and fs-path without
> contacting the server, which is important for making a relocate
> operation safe.
>
Yup.
> It looks like we don't store the url or uuid in a file entry if it
> doesn't differ from the parent. I assume we can do the same for the
> repository root.
Yup.
>
> There are other options for making relocations safe, such as
> introducing "entity IDs" (issue #1525) or assigning unique,
> meaningless IDs to node-revisions. But this is the most
> straightforward way, and the one which dovetails best into phase 3.
>
> PHASE 2: ???
>
> We modify "svn switch --relocate" to use the repository root, if
> present, to verify that the new URLs refer to the same part of the
> repository as the old URLs.
Yup.
>
> PHASE 3: Profit!
>
> We modify "svn switch" (without the relocate flag) as follows:
>
> If the new URL does not match the old repository root:
> Contact the new URL and ask for the uuid and new repository root
> If the new uuid matches the old uuid:
> Relocate from the old repository root to the new one
> Finish by doing a regular "svn switch" to the new URL
>
> Then we deprecate "svn switch --relocate" and remove it in 2.0.
Yup.
>
> Comments? I will file an enhancement issue for this plan if no one
> objects. I don't have immediate plans to implement it, so other
> people should feel free to jump on it.
>
+1.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Oct 17 20:30:48 2004