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

Christian Tismer tismer at stackless.com
Mon Jun 4 21:36:53 CEST 2012


On 5/31/12 10:29 AM, Antonio Cuni wrote:
> 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?
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> http://mail.python.org/mailman/listinfo/pypy-dev

Hi,

I really have to second that last statement:
Subrepos are a red herring for me, after having lots of trouble
in our much smaller project..
The idea is qood, but not in the next half or one year at least.

-- 
Christian Tismer             :^)<mailto:tismer at stackless.com>
tismerysoft GmbH             :     Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121     :    *Starship* http://starship.python.net/
14482 Potsdam                :     PGP key ->  http://pgp.uni-mainz.de
work +49 173 24 18 776  mobile +49 173 24 18 776  fax n.a.
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
       whom do you want to sponsor today?   http://www.stackless.com/



More information about the pypy-dev mailing list