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.
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.
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
* 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.
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.
Received on Thu Sep 8 11:14:11 2005