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