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

Re: Status on issue-2897 branch

From: David Glasser <glasser_at_davidglasser.net>
Date: 2007-12-12 21:42:39 CET

On Dec 12, 2007 12:22 PM, David Glasser <glasser@davidglasser.net> wrote:
> Note that I think I have a way to implement that request in the FS (no
> sqlite), by basically making every noderev with mergeinfo link to the
> previous mergerev where mergeinfo changed in a new tag.

For the sake of getting this out of my head:

In addition to the currently-implemented-on-branch new tags
("has-mergeinfo" and "mergeinfo-count"), there will be a
"mergeinfo-changed" flag and a "previous-mergeinfo-change" node-id

A call to svn_fs_change_node_prop(svn:mergeinfo) will cause the
mergeinfo-changed flag to be set. (I'm not sure if it should be set
for 'propdeletes' or not. I think it should be?)

Any time that a node is made mutable (ie, made into a transaction
node), the flag is cleared, and if it had been set, the
previous-mergeinfo-change field is set to the node-id of the noderev
it was cloned from.

I'm not 100% sure what we do when a node is made mutable under a
different path than its created path (ie, you do a copy above some
mergeinfo, and later change something under the mergeinfo)... That is,
I don't know if the linked list should "stop on copy" or not. Maybe
it should. In that case, the previous paragraph's thing only sets the
previous-mergeinfo-change field if the previous node was at the same
path; also, it should be cleared for a node which itself copied.


David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 12 21:59:11 2007

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.