On Tue, Oct 18, 2011 at 4:19 AM, Bob Archer <Bob.Archer_at_amsi.com> 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.
>> Partial relocation would effectively be detachment without actually moving
>> the content.
>>
>> 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.
>>
>> 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'm a bit annoyed at myself actually. I've been ill on and off for some months
>> and really should have looked into this as soon as useful binaries were being
>> made available (thank-you TortoiseSvn for all of those handy pre-beta builds
>> I played with). Unfortunately, and totally by accident, the testing I did do had
>> me switching while at the WC root.
>>
>> Still I am curious that effort was made to put an informative error message in
>> when it seems it could have been avoided (or used only when paths were
>> supplied that weren't WC roots - though would it have hurt to just switch
>> their roots too).
>
> My assumption is that since in 1.6 you WERE able to switch a non-root folder to another path and in 1.7 it automatically fell back to switching the root the user would expect that the folder only was switched and have issues later on. So, in 1.7 it tells you if you are switching a non-root path that you can't do that and switch the root path. Make sense?
I would have considered it reasonable that, given 'relocate' is a new
command, it could have different semantics to 'switch --relocate'.
It feels like a missed opportunity and a user burden and somewhat
reduces the value of it being a new command (since it enforces an
avoidable weakness of the old one). All it has really done is provide
a more visible command (albeit with a name I don't feel it that much
clearer than switch and so not necessarily more discoverable).
At least the implicit relocation is currently an error with a message
that indicates the alternate behaviour so a future release (I guess
1.8 at the earliest) could rectify it in an unsurprising and
backwardly compatible way (though it doesn't sound like many people
agree that the current UI choice was a mistake).
--
Talden
Received on 2011-10-18 03:04:16 CEST