gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnu-arch-users] factoring changes (re: into the ether)


From: Thomas Lord
Subject: [Gnu-arch-users] factoring changes (re: into the ether)
Date: Tue, 01 Nov 2005 09:39:03 -0800

rwa:
 > I would like not only to accept/reject, but to factor hunks into an 
 > arbitrary number of other trees that I create on the fly during the 
 > process.  Disposing of a hunk would be a special case of that.
 [...]
 > Another problem with the accept/reject process that makes it a 
 > non-starter IMO is that the tree you are committing never exists 
 > as a fully formed tree that you can build/test/etc.  Factoring out
 > into working directories allows you to apply your build/test process 
 > to each state of the tree independently before committing.

That doesn't require any changes to Arch and you should be able
to get an "80% solution" up and running in perhaps a day.

The missing 20%: let's skip thinking about renames, for the
moment -- only worry about file patches.

In your messy tree, run `changes' and save the changeset that
has all of the changes smashed together.

Run an awk script over each patch file in the changeset.  It
should insert, at column 0, for each line of each hunk, the
string "#1#".

Let's suppose you want to factor this into 5 trees which we'll call
1..5.

Using your favorite text editor, examine each patch file in the
changeset.  Decide which tree you want a given hunk in and 
replace the "#1#" accordingly.  For example, if a hunk should 
go in tree 3, make that "#3#".

Check out the immediate ancestor into five trees.  Copy the editted
changeset into each tree.

Run an awk script on each copy of the changeset that does two things.
First, in tree N, it must remove the "#<N>#" prefixes.  Second, as
it does this, it must keep track of the number of lines added and
deleted by hunks for trees 1..N and, in the tree-N hunks, modify the
line number offsets at the top of the hunk accordingly.

Apply the resulting changesets to their trees and voila -- factoring
done.

Of course, you're free to make a fancier UI that does essentially the
same thing.

Extension to renames is harder.  I don't think you want to edit the
"{mod,orig}-{files,dirs}" files by hand so a UI of some sort is a
prerequisit.  I'll leave as an exercise for someone to work out the
right interface and graph math for such a tool.  Having generated
the 5 (or whatever) modified copies of these inventories, it's 
then necessary to rearrange the tree of patch files.

-t






reply via email to

[Prev in Thread] Current Thread [Next in Thread]