[Python-Dev] Mercurial conversion repositories

[Georg Brandl]

On 25.02.2011 17:12, Barry Warsaw wrote:
> On Feb 25, 2011, at 01:50 AM, Raymond Hettinger wrote:
> 
>>
>>On Feb 25, 2011, at 12:09 AM, Martin v. Löwis wrote:
>>
>>> I think I would have liked the strategy of the PEP better (i.e.
>>> create clones for feature branches, rather than putting all
>>> in a single repository).
>>
>>In my brief tests, the single repository has been easy to work with.
>>If they were separate, it would complicate backporting patches
>>and merges.  So, I'm happy with how George and Benjamin put this together.
> 
> The way I work with the Subversion branches is to have all the active branches
> checked out into separate directories under a common parent, e.g.
> 
> ~/projects/python/py26
> ~/projects/python/py27
> ~/projects/python/trunk
> ~/projects/python/py31
> ~/projects/python/py32
> ~/projects/python/py3k
> 
> This makes it very easy to just cd, svn up, make distclean, configure, make to
> test things.  How can I do this with the hg clone when all the branches are
> in the single repository, but more or less hidden?  After doing the 'hg clone'
> operation specified by Antoine, I'm left with a single cpython directory
> containing (iiuc) the contents of the 'default' branch.

Two scenarios are possible:

* You make a clone per branch with the full history, with the current branch
  being different in each of those.  Since "hg update" updates to the head of
  the current branch, this should be easy to do.  When you pull from the single
  repo you will get changes for the other branches as well, but they will not
  bother you.

* You make a clone per branch, containing *only* the respective branch (with
  its ancestors).  This is done by using "URI#branchname" as the source when
  cloning/pulling.

Both should work equally well, with the former giving larger repository sizes,
and the latter taking somewhat longer on the initial clone.

Georg