Re: Subversion 1.7 and 'relocate'

On Tue, Oct 18, 2011 at 3:03 AM, Talden <talden_at_gmail.com> wrote:
> 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).

Indeed, I also don't agree this is bad UI choice. All the other
subcommands that operate on the working copy, they always act upon the
given target path (which is '.' by default). There is not a single
other (sub)command that automatically does something to the working
copy root. Besides, who is to say that we will never be able to
implement 'svn relocate subdir' in the wc-ng-world?

It would also be a total surprise to people who are used to the 1.6
behavior, which can do a relocate of a part of the working copy
("What? I asked it to do something to /my/sub/sub/dir, and it suddenly
relocated my entire working copy behind my back?"). I think such a
change would have caused a lot of complaints.

That said, maybe there is room for a general enhancement (for a future
svn version), to have some kind of alias to mean "working copy root".
Like the '^', which means repository root. Of course, there is always
the problem of different platforms/shells having their special
characters, so I'm not sure if there is a good choice for a special
character here. But then you could say something like 'svn relocate
!', or 'svn merge ^/branches/mybranch !', ... from wherever you are in
the working copy.

-- 
Johan