[kde-freebsd] Proposal for tracking ports tree

[Adriaan de Groot]

Sometimes official ports -- which I consider "downstream" from us -- are changed 
externally. For instance, in response to security issues, or because someone 
else sneaks in a build fix. Ports committers can do that.

But that means that our own copies of ports in trunk can suddenly lag behind 
the official ports. If we don't do anything, merging from trunk to official ports 
-- that's our release process -- might undo progress made downstream already.

This mail proposes a mechanism to make tracking downstream easier.


With an SVN merge, the versioned property svn:mergeinfo is updated. When 
merging between branches in the same repository, a line is added to the 
property with the source branch (e.g. /branches/qt-5.5) and a list of 
revision-ranges that have been merged (e.g. 10990-11872,11875).

There's no particular need for the source to actually *be* in the respository. 
I propose adding a line to the property that reads (right now) PORTS:412647. 
We would read that as "up to ports (downstream) revision 412647 has been 
merged into trunk". As we update by merging downstream into trunk (to keep 
trunk up-to-date on external changes), this would expand to a regular 
revision-range.

I'd like to propose a tool, as well, to help out. It would be given two paths: 
one to an SVN checkout of the ports tree, and one to an area51 checkout. Then 
the diff between the highest revision in the PORTS mergeinfo and HEAD (in the 
official ports tree) would be merged onto the various parts of the area51 tree. 
The svn:mergeinfo would be updated to reflect the newly merged range.

It's pretty close to what kdemerge does, except that this needs to merge diffs, 
not overwrite things: because we're now dealing with two branches that have 
diverged (namely, diverged from the last time trunk was merged to downstream).

To some extent, this can be done from the command-line with SVN itself, but it 
takes a fair amount of hand-administration:

    svn merge -r 412647:HEAD https://svn.freebsd.org/ports/head ./QT

that will pull in changes from the ports tree into trunk/QT .. unfortunately, 
it also pulls in everything that touches the tree that isn't in our subtree 
QT, so afterwards there's a bunch of resolving and reverting to do to clean 
up. And you'd need to svn pe svn:mergeinfo to record the fact of this merge.

I believe this can be done in an automated fashion; I intend to try a little 
python program to do this (because I'm familiar with the python SVN 
interface).


Anyway, my question becomes: does this proposal make sense? Should we actively 
track downstream in case things change there?

[ade]