Such a tool is planned for BitKeeper. There are actually two tools, duals
(if I'm using the term correctly) of each other.
mkpatch - generate a bitkeeper change set as a patch
You use this one to generate your diffs + comment history + change
set log. It works like this:
mkpatch change_set_id > patch
takepatch - apply a bitkeeper change set from a patch
You use this to suck in a patch and apply it. It updates all the
files as well as the ChangeSet file which has an entry pointing
to all the files that you just changed. In deference to Linus'
work habits, it lets you edit the patch before applying it
(it lets you edit a copy of the patch, if you actually do change
anything in the pach, then the patch will go in as two deltas -
the base patch under the user id of the person that sent plus
another delta on top under the user id of whoever changed it).
At this point, I'm planning on insisting that the patch is a named thing,
i.e., a change set. If you hack on your tree for a while and check
everything in, mkpatch won't work unless you've given all that crud a
name and an entry in the ChangeSet file. It's perfectly OK to just call
it "my patch 17" and there will be a tool, probably called changeset, that
you can just say
sfiles -e . | changeset -rlinux-2.1.123 -n'my patch 17'
which says "take everything in my tree that has changed since 2.1.123 and
group it into a changeset called 'my patch 17'". The -e option to sfiles
will error if it finds any checked out and modified files in the tree
rooted at ".".
Oh, the patches generated by mkpatch include keys on a per file basis that
will be used by takepatch to figure out where to apply the patch. This
means you can apply old patches to your tree, they will be branches hanging
off of the delta that was the basis for that change. Maybe that's not clear,
let me try it like this. Suppose that your file looks like
1.1
1.2
and you make it look like
1.1
1.2
1.3*
where 1.3 is starred because that's your work. In the meantime, Linus tree
now looks like
1.1
1.2
1.3
1.4
1.5
When your patch shows up, takepatch will detect that the patch was based on
revision 1.2, not 1.5. If Linus doesn't decide to just reject it and force
you to bring it up to date, takepatch will produce a file that looks like
1.1
1.2
1.3 1.2.1.1*
1.4
1.5
where your delta has been renamed to 1.2.1.1 but is in the graph-wise
correct position, i.e., a child of 1.2, because that's what actually
happened in your tree. This, by the way, is the cornerstone of bitkeeper,
it's what all other source management systems get wrong (they'd stick your
work plus the merge in as 1.6).
At this point, the only thing that has happened is that Linus has decided
to accept your patch into his tree but it remains unmerged. When he finally
merges it in, the tree will get an extra merge delta like so
1.1
1.2
1.3 1.2.1.1*
1.4
1.5
1.6 (merge in of 1.2.1.1)
I'll try and code thes up in the next week or two, I'm still working
on some other crud but I think I can get to this.
Sound OK?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/