On Saturday 2006, December 02 19:41, Linus Torvalds wrote:
> Now, I'm not exactly sure who wants to use git modules, so this is the
> time to ask: did you hate the CVS/modules file? Or was it something you
> set up once, and then basically forgot about? People clearly use the
> ability to mark certain modules as depending on each other, and aliases to
> say "if you ask for this module, you actually get a set of _these_
> modules".
Never used CVS/modules, but I used svn:externals. I have a few projects that
are libraries that I use in many other projects. So, my directory tree looks
like this:
projects/
libX/
projectP/
libX/
projectQ/
libX/
The nightmare I had was that I would add a feature to projectP/libX, and
commit it. Great. Then later I'd do "svn update" in projectQ - HAVING MADE
NO CHANGES TO IT - and libX would update to the latest version, which turns
out to be incompatible with projectQ, and I can no longer even build
projectQ. If only libX would stay where it was put. The worst of it is if
you check out an older version, say "stable-release" that you tagged last
year, the svn:external would always just check out the latest version, so
you'd have to go back through the logs to find out what approximate submodule
revision you should really check out, check it out and then remember not to
do svn update, because that would just reset the external to the latest
version. AHHHHHHH! Maddening to say the least.
This fits exactly with what you have described as the primary reason for
wanting submodules. I didn't want seamless integration, I was happy to
change into projectP/libX to make libX commits. All I actually wanted was
the particular checkout of libX for a particular checkin of projectP to be
remembered. That's it. Anything else is just gravy.
I'm doing exactly the same sort of thing now but with git. git hasn't fixed
the problem (yet) but certainly hasn't made it any worse than it was.
svn:externals were nothing more than a way of storing a URL in the
repository - who cares, I wish now I'd never bothered, they serve no version
control purpose and are merely a UI convenience.
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
andyparkins@xxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html