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

Re: svn commit: propchange - r17029 - svn:log

From: Kalle Olavi Niemitalo <kon_at_iki.fi>
Date: 2005-10-26 21:42:36 CEST

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

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.