[Svnmerge] questions about merge tracking

[Giovanni Bajo]

Archie Cobbs <archie at dellroad.org> wrote:

> I'm assuming you would take your XX:HEAD list and combine it with: the
> 1:XX list after subtracting out already-merged revisions (i.e., from the
> svnmerge-integrated property)... otherwise you'd not show the unmerged
> revisions < XX. By induction, that list would also be "pruned"...

My idea is to silently register phantom revisions as "already merged" in the
property. Thus, I'd maintain this invariant: given XX, the highest revision
mentioned in the svnmerge-integrated property, then any phantom revision in
range 1:XX must be present in the property.

> If so then this makes sense. You'd only need to do it for the normal
> (non "-l" or "-d") cases of "svnmerge avail". It make make things run
> slower though.

Yes, it might, but it makes the output of "svnmerge avail" more correct. We
could have a -p (prune), but I'm +1 for making it the default.


> 1. Don't show "phantom" revisions in "svnmerge avail"
> 2. Auto-merge in "phantom" revisions when we "svnmerge merge".

> What you are referring to is option #1. Option #2 would mean doing
> something like this: Let M be the maximum merged revision number so far.
> Each time we "svnmerge merge", if we are merging a maximal revision
> N > M, then find all the "phantom" revisions between N and M and merge
> them as well.
> I kind of like #2 better because it seems more "proactive" or something.
> We could use a similar "svn log -r M:N ..." trick to detect the phantom
> revisions. Then the "by induction" statement would hold true.

The actual update of the svn merge property will have to be done as part of
the "svnmerge merge", because "svnmerge avail" is not supposed to modify the
working copy. Thus, I believe we should actually implement both #1 and #2.
#1 will make things easier for the user because it will show clearly which
are the available revisions, while #2 will take care of the actual updating
the property.
-- 
Giovanni Bajo