Kobayashi Noritada <nori1@dolphin.c.u-tokyo.ac.jp> writes:
> Should we make logs versioned and make it conflicted or merged when
> editted at the same time?? :-)
Why, of course! I'm thinking of the following goals:
* Let SVK mirrors of a repository receive revprop changes with
reasonable efficiency (i.e. not rescanning the whole history
in every sync).
* Detect conflicting changes of revision properties.
* Allow (but don't require) log entries for revprop changes.
* If a revision property has been changed, then reading that
property should by default return the most recent value,
as the change was intended to retroactively affect history.
* Preserve all previous values of the revision property
somewhere, until they are explicitly obliterated.
* The history of how a revision property was altered can itself
be recursively altered.
So, how about this scheme:
* Each revprop change is assigned a revision number, just like a
commit. For example, changing the log entry of revision 42
might result in a new revision 105.
* When a property of a revision is changed, a svn:last-revprop-change
property is also added or replaced in that revision. The value of
the property is the revision number that was assigned to the revprop
change. Thus, revision 42 would get a svn:last-revprop-change
property with value 105. Conflict checking just compares this.
* The previous value of a revision property is stored as a
property of the revision that was allocated for the change.
For example, if the svn:log property of revision 42 was changed
in revision 105, then revision 105 would have a
svn:old-revprop:42:svn:log property that holds the old log
entry. The revision number is part of the name of the property
so that the scheme allows one revision to change the properties
of multiple revisions.
* The previous value of the svn:last-revprop-change property is
also stored in this way. If a property of revision 42 is changed
in revisions 105 and 123, then the svn:last-revprop-change
property of revision 42 will point to revision 123, and the
svn:old-revprop:42:svn:last-revprop-change property of revision
123 will point to revision 105. By following these links, the
entire history of the revision can be read.
Unanswered questions:
* How to transfer this information over the wire?
* Does this hurt compatibility?
* Should the repository GUID be stored with the revision number?
* How to log an added or removed revision property?
* How does one tell svn propset --revprop what value of
svn:last-revprop-change it should expect? (There is no such
problem with svn propedit --revprop.)
* Can a reverse svn merge of such a meta-revision undo the revprop
change, and how does that affect svn:last-revprop-change?
- application/pgp-signature attachment: stored
Received on Wed Oct 26 21:36:50 2005