On 25.02.2011 17:31, Georg Brandl wrote:
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.
Ah, and the latter obviously also won't work with the "hg-native" workflow (merging between the branches using hg merge).