Jesse Noller writes: > On Sat, Jul 3, 2010 at 7:05 AM, Dirkjan Ochtman <dirk...@ochtman.nl> wrote: > > On Sat, Jul 3, 2010 at 12:53, Stephen J. Turnbull <step...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com