You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Talden <ta...@gmail.com> on 2011/10/14 02:08:28 UTC
Subversion 1.7 and 'relocate'
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?
If my current folder is c:\work\foo\bar and my working copy is rooted
at c:\work\foo I can't just 'svn relocate MIRROR_PREFIX
MASTER_PREFIX'.
Oh no, instead svn tells me how it knows the right answer but that I
should be a good doggy and jump through some hoops first...
svn: E155019: Cannot relocate 'C:\work\foo\bar' as it is
not the root of a working copy; try relocating 'C:\work\foo' instead
No shit Sherlock.
It would be nice if invocations with no paths specified just relocated
the entire working copy (the relocation itself is awesome fast though,
thanks WC-NG folks).
NB. Yes I know about the write-through proxies with subversion using
http. No, for internal reasons, switching between our LAN mirror and
our very slow opposite-hemisphere master is necessary, extremely
useful and very frequent.
--
Talden
Re: Subversion 1.7 and 'relocate'
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Sperling wrote on Fri, Oct 14, 2011 at 02:12:55 +0200:
> 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
I'd guess something about not operating on parent directories of the
target directory (in this case, the implicit ./ target). Perhaps
% svn switch --relocate --from-wc-root
is needed?
Re: Subversion 1.7 and 'relocate'
Posted by Talden <ta...@gmail.com>.
On Fri, Oct 14, 2011 at 11:46 PM, Stefan Sperling <st...@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 <st...@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
Re: Subversion 1.7 and 'relocate'
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Oct 14, 2011 at 03:20:05PM +1300, Talden wrote:
> On Fri, Oct 14, 2011 at 1:12 PM, Stefan Sperling <st...@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.
RE: Subversion 1.7 and 'relocate'
Posted by Bob Archer <Bo...@amsi.com>.
> > On Fri, Oct 14, 2011 at 1:12 PM, Stefan Sperling <st...@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?
>
> BOb
Everywhere I wrote switch above you can also read as RELOCATE.
BOb
Re: Subversion 1.7 and 'relocate'
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Ulrich Eckhardt wrote on Wed, Oct 19, 2011 at 11:34:03 +0200:
> Am 18.10.2011 10:02, schrieb Daniel Shahaf:
> >Johan Corveleyn wrote on Tue, Oct 18, 2011 at 09:48:46 +0200:
> >! is special in unix shells. But ^./ for the wc root?
>
> The caret ("^") is special in other shells, namely cmd.exe. Also,
> wasn't the caret already used to refer to the repository root?
^/ refers to the repository root. ^./ is not special and re-uses the
character that has learnt to escape and gotten used to escaping.
http://subversion.tigris.org/issues/show_bug.cgi?id=3883
Re: Subversion 1.7 and 'relocate'
Posted by Ulrich Eckhardt <ul...@dominolaser.com>.
Am 18.10.2011 10:02, schrieb Daniel Shahaf:
> Johan Corveleyn wrote on Tue, Oct 18, 2011 at 09:48:46 +0200:
> ! is special in unix shells. But ^./ for the wc root?
The caret ("^") is special in other shells, namely cmd.exe. Also, wasn't
the caret already used to refer to the repository root?
Uli
**************************************************************************************
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at http://www.dominolaser.com
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************
Re: Subversion 1.7 and 'relocate'
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Johan Corveleyn wrote on Tue, Oct 18, 2011 at 09:48:46 +0200:
> 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.
>
! is special in unix shells. But ^./ for the wc root?
Re: Subversion 1.7 and 'relocate'
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Oct 18, 2011 at 3:03 AM, Talden <ta...@gmail.com> wrote:
> On Tue, Oct 18, 2011 at 4:19 AM, Bob Archer <Bo...@amsi.com> wrote:
>>> On Fri, Oct 14, 2011 at 1:12 PM, Stefan Sperling <st...@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
Re: Subversion 1.7 and 'relocate'
Posted by Talden <ta...@gmail.com>.
On Tue, Oct 18, 2011 at 4:19 AM, Bob Archer <Bo...@amsi.com> wrote:
>> On Fri, Oct 14, 2011 at 1:12 PM, Stefan Sperling <st...@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
RE: Subversion 1.7 and 'relocate'
Posted by Bob Archer <Bo...@amsi.com>.
> On Fri, Oct 14, 2011 at 1:12 PM, Stefan Sperling <st...@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?
BOb
Re: Subversion 1.7 and 'relocate'
Posted by Talden <ta...@gmail.com>.
On Fri, Oct 14, 2011 at 1:12 PM, Stefan Sperling <st...@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).
--
Talden
Re: Subversion 1.7 and 'relocate'
Posted by Stefan Sperling <st...@elego.de>.
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