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.
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.
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.
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.
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.
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.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Oct 17 18:32:43 2004