[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] is monotone for me?
From: |
graydon hoare |
Subject: |
Re: [Monotone-devel] is monotone for me? |
Date: |
04 Nov 2003 11:55:59 -0500 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
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