Re: [Monotone-devel] is monotone for me?

[graydon hoare]

Andreas Jellinghaus <address@hidden> writes:

> I wonder if whenever I did some change, I could tell monotone: this
> isolated change is a new branch. but my working copy is a merge of
> one or several branches plus maybe some uncommited work. Also when I
> update some change, I should be able to tell that change is an
> update belonging to that isolated branch.

yes. the way to do this is with separate branches, and use of the
"propagate" command. it is designed for such circumstances;
unfortunately we really need to expand the manual to cover how to use
it properly. here is how I propose you do your work habit (supposing
you are working on project "happycode"):

1. import releases into 1 branch: 

   de.inka.dungeon.happycode

   or else just use their existing branch (say net.sf.happycode)

2. if you want to add feature X, and fix Y and Z, make 3 new branches:

   de.inka.dungeon.happycode.add-x
   de.inka.dungeon.happycode.fix-y
   de.inka.dungeon.happycode.fix-z

3. to test all your changes together, make 1 new integration branch:

   de.inka.dungeon.happycode.integration

4. now, when a new version happens upstream, you do:

   $ tar -xzf happycode-x.y.tar.gz
   $ monotone --branch=de.inka.dungeon.happycode commit "x.y import"
   $ for i in add-x fix-y fix-z
     do
       monotone propagate de.inka.dungeon.happycode \
                          de.inka.dungeon.happycode.$i
     done

   this will locate the least common ancestors between each change
   branch and the upstream (the last merge point) and do a 3-way merge
   with the changes from upstream and your edits, depositing the
   result in the edit-specific branches.

5. you can then work on your changes off each of those branches, and
   when you are ready to post patches upstream do:

   $ monotone --branch=de.inka.dungeon.happycode heads
   $ X=<...head version of happycode...>
   $ monotone --branch=de.inka.dungeon.fix-x diff $X >fix-x.patch

6. when you want to test all your individual versions together in your
   integration branch, you would do:

   $ for i in add-x fix-y fix-z
     do
       monotone propagate de.inka.dungeon.happycode.$i \
                          de.inka.dungeon.happycode.integration
     done

   this will, again, locate the least common ancestor (last merge
   point) between each edit branch head and your integration branch
   and move all the changes which happened on the edit branches into
   the integration branch, adjusting patch coordinates to reflect
   changes which happened on the other edges. then you just go to a
   scratch dir and do:

   $ monotone --branch=de.inka.dungeon.happycode.integration co .
   $ ./configure && make check

   to test that everything works well together. 

note that this kind of use of monotone is still rather immature and
poorly tested, so while it looks like it will work on paper, we
haven't any positive examples of large trees doing this sort of
thing. there are probably some bugs lurking.

> monotone like the other rcs systems focus on managing sets of files,
> and diffs are the side product of that work. While I actualy want to
> manage mostly diffs, and different sets of files are the mere side
> product for me. I wonder if monotone can still help me.

while this is certainly true, it is also true that the ancestry
information contained in a graph of versions helps decide how to
"rediff" changes when new siblings become available and you wish to
incorporate some of their changes. it can also be done with patch-log
oriented VC systems, such as darcs, but requires looking inside
patches and modifying them.

-graydon