You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by John Belmonte <jo...@neggie.net> on 2004/12/27 03:22:39 UTC

versioned revprop changes

I haven't tried an implementation, but here is a non-invasive plan for 
versioning revprop changes so that they are preserved across incremental 
repository mirrors.  (See 
<http://subversion.tigris.org/issues/show_bug.cgi?id=1755>.)

The idea is to map revision properties to versioned file properties.  In 
  the master repository, the revprop hook causes a commit of the 
corresponding versioned property.  In the slave repository, the commit 
hook watches for the file property changes and turns them back into 
revprops.

For the mapping, you could dedicate a repo directory called 
/altered_revprops which contains a file for each revision with altered 
properties.  For example, svn:log on revision 10 will map to the 
identically-named property on /altered_revprops/10.

Tricky points that I can think of:
     * When an existing property of a certain revision is altered for 
the first time, we want to record the old value for posterity.  One 
solution is to make two commits: one to set the old value, and another 
to set the new value.  (The first commit is harmless to the slave 
repository.)  An alternative is to only do one commit, storing the old 
value using a special suffix (e.g. svn:log becomes svn:log.orig), and 
have the slave repository ignore properties with this suffix.

     * There are some transactional issues.  If the versioned property 
is committed from the pre-revprop-change hook, and then the revprop 
transaction fails for some reason (e.g. power outage), the slave will 
pick up a change that never happened.  The opposite problem exists if 
you instead commit from the post-revprop-change.  Similar issues exist 
with the commit hooks on the slave side.

     * To be complete, the revprop hook would have to retry a failed 
commit caused by the same revision being modified in the time since the 
working copy was created.


-John

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org