[Python-Dev] SVN <-> HG workflow to split Python Library by Module (original) (raw)

Stephen J. Turnbull stephen at xemacs.org
Tue Jul 6 05:12:18 CEST 2010

Jesse Noller writes:

On Sat, Jul 3, 2010 at 7:05 AM, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:

On Sat, Jul 3, 2010 at 12:53, Stephen J. Turnbull <stephen at xemacs.org> wrote:

The point of submodules a la git is subtly different.  It is that you can mix and match known versions of the modules.  So, eg, in order to work on recent urllib, maybe you need a recent but stable email but you don't want any of the work being done on removing the GIL because it's somewhat unstable.

This sounds like it could also be done with good branching + merging.

Cheers,

Dirkjan

What Dirkjan said; since using mercurial more and more lately, local branches are an insanely good tool and method of coordinating work

I have nothing against local branches as a tool and method of coordinating work. But what Dirkjan said is insufficiently precise. It's not about the branching and merging operations (submodules are, after all, just a way of specifying certain branch/merge patterns). It's about knowing certain things about what's in the branch, and how the content is referenced (ie, with submodule-local tags, rather than project-global tags). It's about modularity over history, as well as in the static, instantaneous structure of the application.

Since history needs to be modular, too, it might not work as well as I made it sound above, I admit. But there are times when such a capability is quite useful, and in the stdlib it seems likely that most of the modules will have sufficiently independent histories.

Consider the problem going backwards. You have a current Python 3 in your workspace, and you suddenly realize that if you rewind the GIL (core) work to about March a nagging intermittent bug will go away, but email needs to be at least May 1 but no later than June 15. How do you spell that without submodules, or a preexisting branch that happens to have exactly the right stuff in it?

I know it can be done, but it requires some thought and quite a bit of dexterity with branching, checking out the right versions of the right files and overlaying them on the branch you are creating without pulling in unwanted versions of other files. Now, how do you keep that branch updated with bugfixes and stuff that doesn't directly affect your current work? You'll have to keep rewinding the GIL- related and email-related files by hand. Submodules make that easy.

More information about the Python-Dev mailing list