>> hg update release32-maint
>> patch
>> hg commit
>> hg update default
>> hg merge release32-maint
>> hg commit -m merged
>> hg push
>>
>> Sprinkle test runs into this to your taste.
>
> What about compiles?
Good question; this is beyond my hg-FU. Approaches that might be worth
trying are:
- have separate build directories, all referring to the same source
directory. Python currently doesn't fully support that (i.e. there
are cases when the source directory is changed), but people have been
asking that this gets supported for a long time.
- share repositories across multiple checkouts, using symlinks. Not
sure whether this is supported.
- Make local clones, one per branch, and then push across them.
E.g. the flow might change to
cd 32
hg pull -u upstream
patch
build
hg commit
cd ../trunk
hg pull 32
hg merge
build
hg commit -m merge
hg push upstream
Notice that the push and the pull come from different clones: you
would pull into the 3.2 clone, and eventually push from the trunk
clone.
As for the "32" references above: the first one is a directory;
the second is a named source (from ..hg/hgrc). Not sure whether
"hg pull ../32" would work as well.
> And perhaps even make distclean/configure? With our
> current workflow I have separate checkouts for 2.7, 3.1, and 3.2, and
> run make when I see a c file go by after an svn up (and make distclean if
> I see an update to a .in file, though I know that isn't always necessary).
At least the third one should be identical to your current setup, except
that
a) changes flow into the other direction, and
b) there is no server communication to move patches across branches
(whereas in subversion, you commit to the server, then svnmerge
from the server).
Regards,
Martin
_______________________________________________
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
