Disclaimer

The content of this blog is my personal opinion only. Although I am an employee - currently of Imagination Technologies's MIPS group, in the past of other companies such as Intellectual Ventures, Intel, AMD, Motorola, and Gould - I reveal this only so that the reader may account for any possible bias I may have towards my employer's products. The statements I make here in no way represent my employer's position, nor am I authorized to speak on behalf of my employer. In fact, this posting may not even represent my personal opinion, since occasionally I play devil's advocate.

See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.

Wednesday, March 30, 2016

Back to the future: RCS

I have long been frustrated by the poor support for nested repositories in all version control systems that I am aware of:  Mercurial, Git, Bazaar...



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.