Yeah, yeah, Git 2.8 has better submodules support. Mercurial has subrepos. Blah, blah, blah.
My problem with all of these that I have looked into in detail is that they require a posteriori identification of a module. And there is overhead at the root of a modules.
Whereas I have, for many years, maintained a personal source code tree where nearly any subdirectory tree and any time can be cloned, and used independently. I do this because I want to use arbitrary libraries of my own in arbitrary other projects - e.g. my employer does not want me to insert my entire library tree into any source code of theirs, not if I just have too random libraries from disconnected places in my tree. I also try to structure my libraries so that the minimum necessary can be imported.
TBD: Insert anecdote about discussing this with Linus - after his explanation, he said "Yeah, you need to add a porcelain to git."
But not just a porcelain. I do not usually want the whole history of the whole repository, all the way up to its root. Usually I want only the subdirectory tree history (with provision for files in the subdirectory that may have been moved, i.e. that may have history, outside the tree).
And often I do not want the history at all, just a pointer to the repo.
E.g. today: I want to import one of my libraries for the umpteenth time into a project at work.
Way back when I started doing this regularly, my personal source code tree was CVS, as was my company's. You can make a CVS directory be a symlink to outside CVSROOT, and it works pretty well. (Except that the company history doesn't have its own history of my tools.)
I have not found an equally satisfactory system since I gave up CVS.
Oftentimes, I use two VCS in the same module:
My company may be using Perforce, /p4/workspace/project
My library may be in ~glew/src/lib/a/b/glewlibXX, under Mercurial (or git, or bzr, or...)
and I clone my library using my VCS to the company workspace
Possibly in
/p4/workspace/project/users/glew/src/lib/a/b/glewlibXX
But preferably in a better location, like
/p4/workspace/project/external-dependencies/glewlibXX
I check all of the files into the company repo (perforce).
When I edit, I check into the company repo using the company VCS, e.g. perforce. If I am allowed, I also check into the my personal repo using my VCS, e.g. hg.
If the company wants, they can pull updates that I have made to my personal library from my VCS into their VCS. And so on.
If I am using a DVCS, this creates a history, typically
/p4/workspace/project/external-dependencies/glewlibXX/.hg
This wastes diskspace, since the company has its history in their depot, and I have my history in mine. But we don't care about diskspace any more, right?
It's a minor pain, since I have to remember to push history from
/p4/workspace/project/external-dependencies/glewlibXX/.hg
to
~glew/src/lib/a/b/glewlibXX,
in addition to having to checkin to the company repo.
I can automate that.
A bigger annoyance is the question: does the cloned module's history and metadata,
/p4/workspace/project/external-dependencies/glewlibXX/.hg,
get checked into the parent repo? I.e. is there a history of the history?
I have tried it many both ways. Either way has problems
Anyway: frustrated, I have been thinking about going back to what worked well..
I was considering going back to CVS, since as I mention above it is fairly easy to link CVS directories.
The annoyance there is that CVS requires CVSROOT. And I would prefer not to go back to having a full CVS repo.
Anyway: frustrated, I have been thinking about the simplest possible thing.
If not CVS, then next simplest is RCS. (Or maybe SCCS, but I would rather not think about that.)
I.e. I am considering using RCS, only for this submodule sharing. I would be using a different VCS for my master, and the company would continue to use its own.
I.e,. RCS might be just the VCS for fine grain submodule sharing.
I will use comments to this post to record further thoughts and issues.
