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@python.org http://mail.python.org/mailman/listinfo/pypy-dev
