[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Karl Fogel <kfogel_at_red-bean.com>
Date: 2007-09-19 08:40:41 CEST

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.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 19 08:40:53 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.