The content of this blog is my personal opinion only. Although I am an employee - currently of Nvidia, in the past of other companies such as Iagination Technologies, MIPS, 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.

Monday, January 30, 2012

Version controlling VCS metadata

My project .hg/hgrc is growing pretty long.

It needs to be under version control.

Unfortunately, hg does not, refuses to, version metadat such as .hg/hgrc.  Security.  Since .hg/hgrc may contain executable hooks...

Seems to me there should be a better way. E.g. disabling it's executability, although allowing it to be versioned.

Or - since some (but by no means all) such metadata is per repo, and is meaningless in a clone, perhaps there should be a meta-VCS system.  This is fairly natural for me, since i have had my repos nested within each other for decades.

Unfortunately, not so natural for Mercurial.

Symlinks to URLs


As people have explained, although you can create a symlink that links to an URL, it does not accomplish much.  UNIX is not smart enough to look at the link content, recognize it as an URL, and then do something appropriate to it.

Nevertheless, I occasionally do create symlinks to URLs.  Mainly just as documentation - I am used to going to looking at ~/links/* when I forget where, on the filesystem, I have stored something.  It's not much of a stretch to do the same thing for URLs.  However, doing so tends to break consistency checks and other stuff that assumess or requires that symlinks point to valid filesystem locations.

Furthermore, I have made some of my own tools smart enough to recognize that, if they see a symlink where an URL is needed, that they should dereference the symlink and look at its contents.  More and more of my tools treat URLs and paths in the filesystem as interchangeable.  Assuming, of course, that the URL protocol has appropriate methods for reading and writing.