[python-committers] [PSF-Members] Code Simplicity » Open Source Community, Simplified

["Martin v. Löwis"]

>> 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