2013/7/10 Stephan Beal <[email protected]>:
> i might have over-thought that problem: closing on merge "probably" isn't a
> problem here because if the leaf is closed that doesn't hinder us at all.
> Closing a leaf keeps us from committing to it, but not from pulling from it.
> To me closing at merge time sounds like the overall easier approach (but i'm
> very possibly ignoring/missing details/complications which i'm hoping
> another list member will point out).
The only thing to consider is that the "merge" command doesn't do a
sync, so the merged branch might be closed, but no-one else knows
that until a commit(with sync) is done. What if - in the mean time -
someone else does a commit in the to-be-closed branch? Later, when
we do the commit, we are trying to close a node which has successors.....
Should the commit fail then?
And adding a sync after performing a merge-with-close doesn't seem
a good idea either: a merge is a local operation now, which cannot
fail (assuming the merged branch does exist)
A way out could be the following. In the "vmerge" table, the "id"
field is used for indicating what type of merge it is:
0: MERGED_WITH
-1: CHERRYPICK
-2: BACKOUT
A new value -3 could be added here meaning MERGE_WITH_CLOSE.
Then, when committing, a check could be done whether the merged
branch is still a leaf. If so, the branch is closed. If not, a warning
is printed that the branch couldn't be closed, but it will not
influence the success/failure of the commit.
How does that sound?
Regards,
Jan Nijtmans
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
