On the wc-replacements branch Ivan and I are working on finishingbreser's idea to extend libsvn_wc to allow localreplacements-with-history to be represented. Our current wc modeldoes not allow for such situations, but certain merge, copy and moveoperations can result in a situation requireing it. Copy and movehave been explicitly disabled to allow the operation with this endresult, but merge still can produce it - leading to a broken wc.
The problem=========
In order to do diff, update and commit operations, libsvn_wc requiresa text-base for all operations (except add-without-history?). Thissame text-base is used to restore a file to its original contents on'revert'.
When a file is schedule-replace-with-history (same asschedule-add-with-history, but over an existing previously versionedtarget), a text-base is required as described above. When revertingthe schedule-replace-with-history, however, a *different* text-base isrequired to restore the file: the text-base of the file which wasremoved.
That is where the problem is: libsvn_wc only allows for one text-base,not two, to be stored in the admin area.
The solution=========
Well, store 2 text-bases in some situations ofcourse!
Or more precise:
When a copy, move or merge results in a schedule-replace-with-history,create a second text-base which can be used to revert theschedule-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=============
* PropertiesIn 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.
* DirectoriesI have not (yet) investigated the libsvn_wc behaviour withschedule-replace-with-history for directories. This definitely is anitem to finish before calling the feature complete.
* Directory->File replacements v.v.These are not supported for normal replacements and I didn't plan tochange that within the current task.
The current branch status===================
In an initial commit after branch creation, breser committedfile-replacement. After that Ivan submitted patches to bring workingcopy administration up to date.
After that, several tests have been committed and the same solutionhas been implemented for properties.
The end.
So, Ben, I hope this matches the basics of what's required to doreview as an uninformedly passing committer wanting to.
BTW: In another thread I started a discussion about our currentbehaviour on Tree-conflicts, which I think are currently somewhat'unhandled'. The wc-replacements task does not include changing that,but I think it's still a good idea to reflect on that part of ourdesign some more.
bye,
Erik.
Received on Thu Sep 8 11:14:11 2005