[pypy-dev] change of strategy for the py3k branch?

[Antonio Cuni]

On 05/30/2012 04:04 PM, Armin Rigo wrote:

> Then we can probably arrange things so that we use "translate.py" from
> default, and not from the "py3k branch", which would be stripped of
> the translation parts.
> 
> More precisely, we could organize this "py3k branch" --- quotes,
> because likely living then in another repo --- with an only marginally
> different directory structure: e.g. call the top-level directory
> "py3k" instead of "pypy".  Then you would use the default's
> "translate.py" to translate it, without getting conflicts between
> "pypy.interpreter" as used by translate.py and the new
> "py3k.interpreter" containing what you are translating.
>
> Of course the directories that would be in the py3k package would
> still have the same name as their original ones, so that we keep open
> the possibility to do merges without adding yet another layer of
> troubles.

uhm, that's an interesting possibility, I didn't think of it. I wonder if
mercurial handles merges well if we rename the top-level directory.

To make things cleaner and easier to understand, we should probably also "hg
rm" from py3k/ the directories which belongs to the toolchain, just to avoid
confusion. I think that in this case at each merge mercurial would ask what to
do with file X which has been deleted locally but changed remotely, but this
is probably something that we can handle.

As I said earlier, the drawback of such "decoupling" solutions is that as soon
as you have two separate repos, you'll get troubles such as "you can translate
revision XXX only if the pypy repo is at version YYY", which can be
frustrating especially when you want to go back in the history.

In theory mercurial subrepos are supposed to solve this problem, but in
practice we should stay as far as we can from them :-(.

Amaury: opinions on Armin's proposed solution?