monotone-devel
[Top][All Lists]
Advanced

[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




reply via email to

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