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

[merge tracking] Prop changes to the "svn:mergeinfo" property

From: Daniel Rall <dlr_at_collab.net>
Date: 2007-03-13 21:06:49 CET

On the merge-tracking branch, we record merge history in the
"svn:mergeinfo" property. A path's merge history is inherited by any
child paths, down until another child path has an explicit
"svn:mergeinfo" property (at which point the value inherited changes
to that of the most recently encountered "svn:mergeinfo"). Example:

  /
    trunk/ <-- svn:mergeinfo=/branches/sparse-directories:3-7
      subversion/
        test/ <-- svn:mergeinfo=/branches/sparse-directories:
          cmdline/

By way of being a child of the "trunk/" directory, "subversion/"
inhertis the merge history "/branches/sparse-directories:3-7". The
"test/" directory must've had those revisions reverted, so has no
history for the sparse-directories merge source. Its "cmdline/"
directory inherits the same.

In the merge-tracking/TODO file (where we've been doing light-weight
status tracking, a la sparse-directories/branch.README), there are a
couple items related to prop changes. However, this use of inherited
properties is currently unique in Subversion -- there is no precedent
for the behavior of prop changes in relation to inherited values
(e.g. by way of 'propset', 'propedit', and 'propdel').

We already provide the 'merge --record-only' command for changing the
merge history of a path. Should the behavior of our prop change
commands/APIs change such that they act on inherited property values,
rather than the explicit values they work with today? Or should the
behavior remain the same? I tend to think the latter. Thoughts?

  • application/pgp-signature attachment: stored
Received on Tue Mar 13 21:07:08 2007

This is an archived mail posted to the Subversion Dev mailing list.