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

versioned revprop changes

From: John Belmonte <john_at_neggie.net>
Date: 2004-12-27 04:22:39 CET

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
Received on Mon Dec 27 04:23:55 2004

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.