On Fri, Oct 14, 2011 at 11:46 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> 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
As I said. A different question. I am _not_ trying to detach - we
relocate for performance.
>> 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?
To state it more clearly.
The reason to relocate for us, is performance. 10-100+ times faster
than performing operations against the master.
Accessing the local mirror is faster so we switch to it whenever we
can - we have to switch to the master for commits.
Yes I'm aware of the write-through proxy - no I can't use that
facility (I also can't use wandisco). Being able to relocate between
servers is useful to us, far more useful than just for 'moving servers
around'. Since the subversion commitment to the feature meets our
requirements, I'm commenting on the inconvenience of the UI -
especially given the constraint that relocation is always an entire
working copy anyway and that subversion reports, in the error message,
what it just should have done itself.
Our slave polls the master at a high rate - obviously you can't switch
back to the slave before it's caught up from a commit you've just made
against the master. We only switch to the master to commit.
NB. relocating between mirror and master used to take nearly a minute
(number of control directories to lock, update, unlock). 1.7 makes
this ~2 sec. Relocating is even more of a performance win than it was
- almost any operation is faster to do against the mirror even when
you're not currently located at the mirror (relocate, do operation,
relocate almost always beats the master 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.
IMHO that's a disservice to the user, burdening them with a poor UI
rather than expecting them to learn such a simple concept.
As you've noted, feedback is an option, simply having the command
report the working-copy root that it relocated would have been fairly
clear feedback (and the effort to undo relocation is cheap for rare
time that this learning experience occurs). I'd have expected that
mentioning the entire working copy in the help of the relocate command
would be fine. I'd leave the deprecated 'switch --relocate' doing what
it does now (an error for a subfolder) but mention the 'detach'
command as well when it arrives.
Is UI important? Well that just depends on how often you use it.
As it is I now have a script that parses svn info for the working copy
root and relocates that... woof woof I've jumped through enough hoops.
With the change to a more 'whole working copy' centric model I wonder
when 'time to think about 2.0' starts - there are a number of commands
that would benefit from omitting paths meaning the whole tree (update,
commit - especially if the WC root is also typically the merge root,
etc) - obviously this isn't a suggestion to reprioritise the very good
stuff in the 1.8/1.9 future features - but has any effort been made to
think about what of the user experience could be changed/improved if
UI compatibility was not a concern?
--
Talden
Received on 2011-10-14 20:42:49 CEST