Partial working copy relocation

["C. Michael Pilato" <cm...@collab.net>]

Over in another thread[1], a question was raised about the behavior of 'svn
switch --relocate' today.  Namely, if you run 'svn switch --relocate' on a
subdirectory of a working copy (that is, *not* a "working copy root"), what
should the behavior be?

The behavior today is that the subdir and its children -- and only the
subdir and its children -- will be relocated.

On the one hand, this is what you'd expect because Subversion has
historically avoided operating on the parents of operational targets.

On the other hand, is there ever a case where the events that force someone
to relocate a subdirectory of their working copy do not also apply to the
parents of that subdirectory?

Should such commands relocate the whole working copy, from its root down?
Should they simply complain that you've not targeted the root of the working
copy, and prescribe doing exactly that?
Should the code behave as it does today?

-- C-Mike

[1] http://svn.haxx.se/dev/archive-2010-07/0438.shtml,
    http://svn.haxx.se/dev/archive-2010-07/0439.shtml

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Re: Partial working copy relocation

["C. Michael Pilato" <cm...@collab.net>]

On 07/23/2010 03:43 PM, Bob Archer wrote:
> Are there any plans to have some way to indicate a "project root" in svn
> 1.7? Or, will it work the same way... we will know the working copy root but
> not necessarily the project/repository root. Having this might help with
> sub-tree merges as well as the relocate issue being talked about above.

I don't follow how the knowledge of the project root really matters in the
scope of this discussion.  This type of relocate operation is done not when
you want to switch a working copy directory so that it reflects some other
repository tree, but when you want to do a working copy metadata rewrite to
account for a total change in the repository root URL for the project.

So, not:

   # I'd like to work on the 'some-branch' branch now.
   svn switch wc ^/branches/some-branch

But

   # IT has switched from svnserve- to Apache-based SVN hosting.
   svn switch --relocate svn://server/svn/repo http://server/svn/repo wc

However, we've discussed numerous times the value of having some indication
of the root of the project branch -- useful for preventing subtree merges,
useful for possibly storing branch management policies, etc.  No, that's not
planned for 1.7.  But I think it's definitely something we should explore
for future releases.

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

RE: Partial working copy relocation

[Bob Archer <Bo...@amsi.com>]

> On Fri, Jul 23, 2010 at 22:38, C. Michael Pilato
> <cm...@collab.net> wrote:
> > Over in another thread[1], a question was raised about the
> behavior of 'svn
> > switch --relocate' today.  Namely, if you run 'svn switch --
> relocate' on a
> > subdirectory of a working copy (that is, *not* a "working copy
> root"), what
> > should the behavior be?
> >
> > The behavior today is that the subdir and its children -- and
> only the
> > subdir and its children -- will be relocated.
> >
> > On the one hand, this is what you'd expect because Subversion has
> > historically avoided operating on the parents of operational
> targets.
> >
> +1.
> 
> > On the other hand, is there ever a case where the events that
> force someone
> > to relocate a subdirectory of their working copy do not also
> apply to the
> > parents of that subdirectory?
> >
> > Should such commands relocate the whole working copy, from its
> root down?
> 
> > Should they simply complain that you've not targeted the root of
> the working
> > copy, and prescribe doing exactly that?
> My opinion that best way is forbidding relocating subdirectory
> working
> copy, since it's proven to broke parent working copy.
> 
> As far I remember we have the same behavior for svn upgrade now.

I think the biggest problem here is that the working copy "root" doesn't necessarily equate to the project "root" or any logical root. So, someone could have checked out a sub-folder of a project and while that becomes the working copy "root" it isn't the project "root".

Tools like git and hg make it pretty obvious what the root of a project/repository is. Basically everything happens in reference to the root folder of the repository no matter what your pwd is. For example, a merge happens in the full repo not just the sub-folder you are in.

Are there any plans to have some way to indicate a "project root" in svn 1.7? Or, will it work the same way... we will know the working copy root but not necessarily the project/repository root. Having this might help with sub-tree merges as well as the relocate issue being talked about above.

BOb

Re: Partial working copy relocation

[Ivan Zhakov <iv...@visualsvn.com>]

On Fri, Jul 23, 2010 at 22:38, C. Michael Pilato <cm...@collab.net> wrote:
> Over in another thread[1], a question was raised about the behavior of 'svn
> switch --relocate' today.  Namely, if you run 'svn switch --relocate' on a
> subdirectory of a working copy (that is, *not* a "working copy root"), what
> should the behavior be?
>
> The behavior today is that the subdir and its children -- and only the
> subdir and its children -- will be relocated.
>
> On the one hand, this is what you'd expect because Subversion has
> historically avoided operating on the parents of operational targets.
>
+1.

> On the other hand, is there ever a case where the events that force someone
> to relocate a subdirectory of their working copy do not also apply to the
> parents of that subdirectory?
>
> Should such commands relocate the whole working copy, from its root down?

> Should they simply complain that you've not targeted the root of the working
> copy, and prescribe doing exactly that?
My opinion that best way is forbidding relocating subdirectory working
copy, since it's proven to broke parent working copy.

As far I remember we have the same behavior for svn upgrade now.

-- 
Ivan Zhakov
VisualSVN Team