[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] patch serieses
From: |
Nathaniel Smith |
Subject: |
[Monotone-devel] patch serieses |
Date: |
Tue, 7 Nov 2006 22:54:52 -0800 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
There was a discussion on IRC today about quilt/mq/stgit style
workflows:
http://colabti.de/irclogger//irclogger_log/monotone?date=2006-11-08,Wed&sel=5#l9
I suggested that one possible approach to providing such functionality
would be to map quilt "patches" to monotone "branches" (_not_ monotone
"revisions", which is the kind of approach that stgit and perhaps mq
take). For more details, see the chat log above. Then I worked out
how one would do the most complicated sort of operation with this
representation -- reordering "patches" -- and stuck it in a pastebin,
but pastebins expire, so the main point of this email message is to
reproduce this text that I pastebinned in a place that is
well-archived:
Patch series: A -> B -> C. I assume the series order itself is stored
somewhere else; this is just the revision graph that goes along with
that. (Or perhaps the series is not stored at all, but implicit in
the ancestry relationships between the branch heads.):
|\| |
| |\|
A | |
\| |
B |
\|
C
To make the patch series order be A -> C -> B instead, we must:
- remove the "B" changes from C
- apply the "C" changes to B
I.e., we want a revision that has only "A" changes in branch A, we
want a revision that has only "A" and "C" changes in branch C, and we
want a revision that has "A", "B" and "C" changes in branch B.
(Interestingly, the current head of C actually has this property
already.) Also, we want the head of B to be a descendent of the head
of C. (The current head of "C" does not have this property.) The way
to do this is:
|\| |
| |\|
A | |
\| |
B |
\|
C
| <-- this edge is an inversion of the A->B edge merged into C
newC
|
newB <-- this revision is a copy of the old C head
The newC revision is created by merging C and A, using B as a common
ancestor. (To do this with current mtn, just 'co -r h:C; pluck -r h:B
-r h:A; commit'.) Then the newB revision is created by taking the old
C head's roster, re-committing it as a child of newC, and putting the
resulting revision into branch B instead.
-- Nathaniel
--
Damn the Solar System. Bad light; planets too distant; pestered with
comets; feeble contrivance; could make a better one myself.
-- Lord Jeffrey
- [Monotone-devel] patch serieses,
Nathaniel Smith <=