[Python-Dev] SVN <-> HG workflow to split Python Library by Module

[Stephen J. Turnbull]

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.