On Fri, Oct 14, 2011 at 03:20:05PM +1300, Talden wrote:
> On Fri, Oct 14, 2011 at 1:12 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> > On Fri, Oct 14, 2011 at 01:08:28PM +1300, Talden wrote:
> >> Was there a reason that 'svn relocate' was designed to not just switch
> >> the containing working copy when you're in a sub-folder of it?
> >
> > See http://svn.haxx.se/users/archive-2011-10/0134.shtml
>
> That seems a different question. It's asking why they can no longer
> switch just part of the working copy and it's related to the same
> reason you can't copy part of a working tree and still use that as a
> working-tree. The control directories have all been centralised at
> the top of the tree and no 'detach' feature has been provided.
There is an experimental script you can try:
https://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/detach.py
> Partial relocation would effectively be detachment without actually
> moving the content.
Fair enough, but that is, and has always been, no officially
supported use case. The fact that it happened to work because of
the way WC meta data was implemented is no reason for keeping it
working. And it does not matter anymore in any case since relocation
is O(1) now.
> We don't need that (clearly I'm asking for the opposite of that). All
> server interactions (update, blame, checkout, list, log, commit
> (though that's redundant in this discussion), ...) are dramatically
> faster against our mirror (our master repository is located in another
> hemisphere in a deep dungeon at the far end of a communications system
> Mr A G Bell would have been embarrassed by - but then the performance
> is about normal for people used to accessing overseas resources from
> New Zealand). Switching between mirror and master is a highly useful
> and regularly operation.
I don't understand what you are relocating to the master for.
What is the use case? Don't you have a write-though proxy set up?
Are you running write operations against the slave?
Or are you working around the fact that read-operations involving
a just-committed revision fail if the slave hasn't caught up to
the master yet? If so, why don't you just wait until the slave
has caught up, instead of transmitting the same data around
the globe twice, slowing down the master->slave sync operation?
> Since 'relocate' is a new command, does not allow for detaching a
> sub-folder in the working-tree and likely will not be used for that in
> the future, why doesn't it just switch the entire working copy if
> you're currently in one (especially when you're nested 10-15 folders
> deep) and don't specify a path?
>
> Obviously versions < 1.7 required you to specify the root too (ala svn
> switch --relocate) but hey, this is a new command. What gives.
I think the notion here is that the user might not expect the
entire working copy to be modified if a sub-directory is passed
as an argument.
Throwing an error means users understand that invalid arguments were
passed, and that only an entire working copy can be relocated.
The alternative is of course to print a message like "note: the entire
working copy has been relocated". *shrug* Is this really important?
There are much worse problems we need to fix.
Received on 2011-10-14 12:47:34 CEST