WC -> WC copy/move operations and repository access

On Mon, 10 Sep 2007, Mark Phippard wrote:

> On 9/10/07, Eric Gillespie <epg@pretzelnet.org> wrote:
> > Daniel Rall <dlr@finemaltcoding.com> writes:
> >
> > > Yes, you'll always want 'svn cp -g'.
> >
> > Sorry if I missed something, but I still think contacting the
> > repository should be the default, with a separate option to skip
> > the contact. There's the abstract argument that if an option is
> > nearly always required, you've chosen the wrong default. But we
> > have a more compelling argument.
> >
> > Users have been running svn cp for years, without -g, naturally.
> > They hear 1.5 has merge tracking, but aren't going to read the
> > release notes in enough detail to note that they have to use cp
> > -g all the time. Even those who do are going to have trouble
> > adapting their habits. Then, later on, they'll find out that
> > merge tracking "isn't working". I think that's bad.
> >
> > Subversion strives to be WAN-friendly, but does not strive to be
> > distributed, i.e. network-independent. We should optimize for
> > the common case. When someone runs svn cp WC WC on a plane,
> > they'll eventually get an error message about name lookup,
> > connection refused, or whatever, and a warning that we're copying
> > without mergeinfo.
>
> I pushed Dan in the current direction (although it was not hard). The
> feeling is that the current need to contact the repository stinks,
> with our without the -g. It is just too ugly to be the default. We
> decided to do it using -g to make sure that "working code" is in
> place. But the idea was that what this particularly feature really
> needs is a redesign where it does not need to contact the repository
> (defer the mergeinfo or just not need it). Dan and Karl discussed
> some ideas. They think implementing it is doable, but right now it is
> just an unknown amount of effort. So anyway, the feeling was that
> making this behavior the default was just not a good idea.
>
> I am still not convinced that for a lot of "routine" copies that the
> mergeinfo is even needed. Obviously if you are creating a branch/tag
> locally it would be, but it seems like that could be managed.
> Updating scripts etc. to do it would not be hard.
...
> Suppose I have a common scenario where I have a feature branch. The
> root of the branch had mergeinfo set when I created it. During
> development, I move some code around. I do not understand what
> mergeinfo needs to be written and why. The mergeinfo is up on the
> parent and nothing has really changed. Isn't this by far the most
> common WC to WC copy/move scenario?

Yes, this will be the most common scenario. Typical exceptions will
include paths below the level of the branch which have had their
mergeinfo modified (potentially due to other copy/move operations).

Karl wrote:

> FWIW, I think contacting the repository should be the default too.
> Yes, it stinks, but it doesn't stink as much as mergeinfo ever not
> working right by default.
>
> I'd like to find a way to avoid the need to contact the repository,
> via inheritable mergeinfo prop data. But that may not happen in time
> for 1.5.

I would prefer to completely avoid needing to immediately contact the
repository. I've discussed two possible strategies for doing so (with
at least cmpilato, pburba, markphip, kfogel, and glasser):

1) Keep track of local copy/move operations in a manner which queues
up mergeinfo modifications until the repository is subsequently
contacted (e.g. for an update, merge, or switch). Maintain this "soft
mergeinfo" state a WC-specific property which is examined at the
beginning of each repository contact, and tweaks mergeinfo accordingly.

2) Use an "inherited properties" implementation to maintain a local
cache of property values inherited from above the root of your WC
tree. This doesn't alleviate the need to contact the repository to
include a moved/copied path's implied mergeinfo (the contiguous set of
revisions at which an object has been at its current path).