exporting patches like bitkeeper

[Sam Liddicott]

* martin f krafft wrote, On 22/11/08 13:56:
> also sprach Sam Liddicott <sam at liddicott.com> [2008.11.19.1533 +0100]:
>   
>> A set of patches between the source tar and the target released is
>> automatically generated, coping with merging and branching by
>> selecting the paths that have the most number of commits - as was
>> done for the bitkeeper exports.
>>     
>
> Would you elaborate on this a bit? 
sure
> How do you lay out your branches,
>   
it doesn't matter
> how do you or does it select the commits/branches to turn into
> patches, 
it has a concept of "origin" and "release".
It does a git-export on "origin" and then patches from origin..release
> how does it flatten them into a linear series of files, and
>   
using an awk function I wrote, git_linearize, which parses git-rev-list
output to build a DAG and then finds the longest path from release back
to origin.

Unlike git-log which is a commit history, git-rev-list is the revision
history. It includes merges and conflict resolution etc, it is a history
of tree revisions, so I can do git-diff between revisions and get the
actual conflict-resolved merged diff's between revisions, which often is
not quite the same as the output of git-log.

I produce the DAG by git-rev-list --top-order --reverse --parents
^origin release so I skip out a V shaped chunk of ancestors that are
parents to origin. When parsing the git-rev-list output I cut out all
revisions that aren't descended from origin. This gives me a nice ^
(inverted v) shape. I then navigate that from the bottom up (which
explores a V shape) but it intersects with the ^ shape and hopefully I
don't have a lot to explore.

So once I have the path with the most number of commits, I have the best
granularity on patches.

At merges sometimes there will be multiple patches on each branch, but
the branch with the least number of patches will get merged as one
patch. (It's not trivial to keep both sets of patches except in cases
when they don't touch the same files).
> how does it integrate them with the SRPM?
>   
It has origin exported as the Source0, which hopefully is a tagged
upstream release and then a bunch of patches from the packager.

If the packager has a branch with the upstream + a load of patches then
it will spit out a nice srpm.
>   
>> All in all it produces srpms's and spec files full of patches just like
>> the old redhat kernel rpm's.
>>     
>
> So you have dozens of patches? Is each patch useful by itself? 
Depends on the person that managed the patches since the upstream release.
Shortly after release time it will make sense. Many months after release
time there could be a lot of patches.
I've got 1,600 patches until the next samba4 release!
> Let's
> say you have a couple of fixes against upstream, and two new
> features you developed on top of upstream, how does someone else
> extract e.g. the first of the two features for their own use?
>   
The packager does "make srpm" and produces his release which contains
all 4 patches.
Someone else can:
rpm -Uvh blah.srpm

and then grab the patches from .../redhat/SOURCES/patch*

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/attachments/20081124/527ed025/attachment.htm