[RFC] Proposal for adding block/unblock options to merge tracking

This is going to be a bit hand-wavy so bear with me.

The merge tracking requirements calls for adding support for
blocking/un-blocking revisions for merge. We have mostly put this off
for 1.5. There is a --record-only option on merge tracking that is
used for manually identifying merges. This can be used to simulate a
block by saying you merged it. This accomplishes the key part of the
block, in that the revision will not be merged, but it misses out on
the auditing side. You cannot look at a branch and really show that
the revision was not actually merged. Could be an issue in audited
environment like FDA requirements.

This has been raised by users in our CollabNet Merge Tracking Early
Adopter forums:

http://merge-tracking.open.collab.net/

Anyway, I had an idea for something that I think we could implement
without really having to alter our merge tracking code too much.

Add new --block and --unblock options to merge command.

--block would behave like --record-only. It would update the
svn:mergeinfo property, but it would also update a new property, let's
call it svn:blocked. If the revision already existed in svn:mergeinfo
it should probably throw an error.

The reason to update both properties is so that we do not have to
tackle the actual merge tracking code/eliding code etc.

--unblock would remove the revision from both properties. Due to the
eliding rules, it might need to climb the working copy to find the
svn:mergeinfo property. I suppose this poses a bit of a problem in
that it could not exist in the working copy. Would this just be a
reasonable limitation?

I do not think we would want to allow this property to be edited wtih
svn property commands.

A hole exists in that someone could edit svn:mergeinfo instead of
running --unblock. I think this is probably a reasonable hole to just
live with.

So why bother to do this?

1) It gives a degree of auditing today. As long as someone does not
try to break the information, it gives them the functionalitty of the
actual block, as well as the information about what was blocked vs.
what was merged.

2) It gives us something to migrate to in the future. We could change
our algorithms to respect the svn:blocked property as an information
source, like we do with svn:mergeinfo today. We would then do away
with the issue of recording the revision in both properties.

Thoughts? Is this too flimsy to consider?

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org