Re: WC -> WC copy/move operations and repository access

On 9/19/07, Karl Fogel <kfogel@red-bean.com> wrote:
> Daniel Rall <dlr@collab.net> writes:
> > 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).
>
> I think (2) is feasible now -- we already have an idea how to
> implement it, and it would be generically valuable for other features,
> not just mergeinfo inheritance. I've been trying to finish up
> sparse-directories as fast as I can (principally issues #2847 and
> #2844, which are going like gangbusters) in order to work on that.
>
> However, if inherited properties wouldn't alleviate the problem at
> hand, then they should take back burner. IMHO, the fact that 'cp' has
> effectively become a non-local operation is Really Really Bad: users
> are going to freak out about it. We positively *have* to fix it, and
> if solution (1) is the only way, then let's get on it.
>
> Not that I ever want to discourage on-list discussion, but Dan, next
> week when Mark is in town let's make sure this is on the agenda for
> when we meet up.

Let me just restate my thoughts as I do not think anyone has addressed
them directly.

I do not think either of these options are feasible, in terms of
trying to branch on October 12th. I have some question as to whether
we could even branch this year as I see inheritable properties as an
issue that will have its own edge cases and feature creep. For
example, even if we do not expose them in the UI or use the feature to
address other issues (like log templates) we will at least have to
consider how 1.6 will do those things to make sure we are approaching
it right.

So schedule and getting a 1.5 release done is one issue. I wanted to
get the svn copy -g solution in place in case we decide in favor of
getting a release done.

I hate the idea of svn cp contacting the repository. I think we all
do. Where I think I differ from everyone else is that I am not
convinced that creating the mergeinfo in a WC to WC copy is vital. At
least in terms of a release stopper.

We know if you have a relevant subset of your repository checked out
and you are creating branches using WC to WC that it is relevant. The
-g option was added to address this. I do not see this as a problem
for this scenario.

In day to day usage of the cp and mv commands, I fail to see anything
but edge case scenarios where the mergeinfo matters.

I do not want to ship a less than perfect solution any more than
anyone else, but we can spend forever (and already have) dealing with
edge cases. Meanwhile, there are bigger flaws like cyclic merges and
tree conflicts that we are already deferring. I say defer the edge
cases, ship the release and get started on 1.6.

I reserve the right to be convinced that there are fairly common cases
where this info is essential and the -g option is a burden on the
user.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org