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

Re: DESIGN: modelling working copy replacements

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-09-09 13:14:23 CEST

Thanks for this explanation; I had wondered what was happening on that
"wc-replacements" branch.

Erik Huelsmann wrote:
> On the wc-replacements branch Ivan and I are working on finishing
> breser's idea to extend libsvn_wc to allow local
> replacements-with-history to be represented. Our current wc model
> does not allow for such situations, but certain merge, copy and move
> operations can result in a situation requireing it. Copy and move
> have been explicitly disabled to allow the operation with this end
> result, but merge still can produce it - leading to a broken wc.

> The solution
> =========
> When a copy, move or merge results in a schedule-replace-with-history,
> create a second text-base which can be used to revert the
> schedule-replace operation - hereafter to be called revert-base.
> Then upon
> - commit, the revert-base should be removed.
> - revert, the revert-base should be promoted to text-base
> - all other operations: do what we are currently doing with replacements
> The unaddressed
> =============
> * Properties
> In the above scheme properties have had no place yet, but that problem
> (which is the same as the text-base one: properties have one base too)
> can be addressed in the same way as the text-base was.
> * Directories
> I have not (yet) investigated the libsvn_wc behaviour with
> schedule-replace-with-history for directories. This definitely is an
> item to finish before calling the feature complete.
> * Directory->File replacements v.v.
> These are not supported for normal replacements and I didn't plan to
> change that within the current task.
> The current branch status
> ===================
> In an initial commit after branch creation, breser committed
> file-replacement. After that Ivan submitted patches to bring working
> copy administration up to date.
> After that, several tests have been committed and the same solution
> has been implemented for properties.

So, to be clear, properties are no longer an "unaddressed" feature, but a
completed one?

Are copy and move operations with this end result going to be re-enabled as
part of this branch, or is that regarded as a separate enhancement that depends
on this one?

- Julian

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 9 13:15:17 2005

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