Ben Collins-Sussman wrote:
>
> On Apr 16, 2005, at 7:12 AM, Philip Martin wrote:
>
>> Matt Doran <matt.doran@papercut.biz> writes:
>>
>>> After doing that, all working copies that pointed to the original
>>> project were then relocated with "switch --relocate" .... but they
>>> could no longer be updated.
>>
>>
>> Your mistake was to use --relocate, you should have simply switched to
>> the new URL.
>>
>
> Correct. --relocate is only for changing the SVNROOT of the URL. It
> only works when the SVNROOT changes, but working copy still represents
> the same directory in the repository. If the working copy needs to
> reflect a different directory within the repos, then plain old
> 'switch' is what's needed.
Thanks for the explanation .... and sorry about the invalid bug report.
Upon re-reading the help ....
1. Update the working copy to mirror a new URL within the repository.
This behaviour is similar to 'svn update', and is the way to
move a working copy to a branch or tag within the same repository.
2. Rewrite working copy URL metadata to reflect a syntactic change
only.
This is used when repository's root URL changes (such as a schema
or hostname change) but your working copy still reflects the same
directory within the same repository.
.... relocate doesn't sound like the right option, but first isn't very
clear for my scenario either. The help and the book talk about switch
being a mechanism to switch your working copy between branches, not
moving a directory. I guess the names switch and relocate were a bit
confusing in my scenario. Relocate *sounded* like the right option.
Are there any checks that could be added to --relocate to avoid my
mistake. I.e. don't allow the relocate if the "SVNROOT" does change?
Thanks again,
Matt
Received on Sun Apr 17 01:52:21 2005