ISO a version control tool that can manage files that are NOT under a directory tree marked as managed by the VC tool

Question

Most of the version control tools that I am familiar with [*], and all of the modern tools - CVS, SVN, git, Mercurial, Bazaar - have some sort of of "marker" in the directory tree.

E.g. if you want to version control file /a/b/c/file.txt, you establish a repository at some level of the tree, e.g.

/a/b/.bzr
/a/b/.git
/a/b/.hg
/a/b/CVS

Most of the DVCSes actually store the version history in this "marker". CVS does not - instead, the CVS directory contains files that tell you how to get to the actual repository (basically links, although not symlinks or hardlinks). CVS, further, puts a link "CVS" directory in every subdirectory of the working tree, that links that directory to its position in some repository. (Not necessarily the same.)

Q: are there any modern DVCS tools that do NOT require such a link or marker in the filesystem.

E.g. the file under version control is

/a/b/c/file.txt

But the repository is in

/x/y/z/repo/.DVCS-TOOL/{a/b/c/file.txt}

where the {a/b/c/file.txt} part is not necessarily a directory path, but possibly an entry in a database.

So that you can do something like the following from inside the repository:

 > cd /x/y/z/repo
 > DVCS-TOOL add /a/b/c/file.text
 Warning: /a/b/c/file.txt is not under the repository /x/y/z.
 Are you sure that you want to add such an outside-repository file? [y/n]  y
 Absolute or relative path? [ar] a
 > DVCS-TOOL ci 
 /a/b/c/file.text --ci-->  /x/y/z/repo/.DVCS-TOOL/{a/b/c/file.txt}
 > rm /a/b/c/file.txt
 > DVCS-TOOL status
 Missing /a/b/c/file.text --in-repo-as-->  /x/y/z/repo/.DVCS-TOOL/{a/b/c/file.txt}
 > DVCS-TOOL revert
 /a/b/c/file.text <--reverted-from--  /x/y/z/repo/.DVCS-TOOL/{a/b/c/file.txt}
 > echo 'stuff' >> /a/b/c/file.txt
 > DVCS-TOOL ci
 /a/b/c/file.text --ci-->  /x/y/z/repo/.DVCS-TOOL/{a/b/c/file.txt}

and from outside the repo, you might do:

> cd /a/b/c
> echo 'more stuff' >> file.txt
> DVCS-TOOL -repo /x/y/z/repo ci
/a/b/c/file.text --ci-->  /x/y/z/repo/.DVCS-TOOL/{a/b/c/file.txt}

MOTIVATION:

I version control my home directory, plus other changes that I have made to my systems, whether Linux, Cygwin, or Windows.

Sure, I can manage cygwin /, so that I can checkin original plus changes I have made to files like /etc/bash.bashrc and /usr/local/etc/foo.rc. E.g. I can create a /.bzr. (More often I only checkin certain files I have changed, rather than the whole tree, relying on being able to retrieve the distro.)

Plus I can do this on UNIX / Linux systems I own, or have root on.

But if I don't have write access to /, but do to /usr/etc/foo/bar and /etc/baz/bif ... and do not want to have two separate repos, but instead want a "sparse repo".

Or if I want to be able to blow away /cygwin at any time, but still have convenient mapping from /a/b/my-repo/{cygwin/etc/bash.bashrc} to /cygwin/etc/bash.bashrc (and, heck, possibly to /etc/bash.bashrc on other systems)

Or, the Windows example, which I ran into today: I want to version control files like

C:\Users\[USERNAME]\AppData\Roaming\Adobe\FrameMaker\11\Maker.ini

or, the cygwin path

/cygdrive/c/Users/glew/AppData/Roaming/Adobe/FrameMaker/7.2/maker.ini

But I don't want to create a repo at C:.hg or C:\Users\glew.hg or ...

I just want to have one repo, and./or a workspace based or linked to that repo, and commands that know how to deal with target files that are not actually under the repo/workspace.

Q: do you know of a modern DVCS tool that does this?

Q: if so, how?

E.g. I vaguely know that bzr allows workspaces to share repos - but AFAIK there still needs to be a /a/b/workspace/.bzr file that links the workspace to the repo. So I'll need more details than "look at Bazaar".

E.g. I know that hg has a --repository option. But it does NOT do what I want:

> cd /tmp
> mkdir tmp1; cd tmp1
./tmp1
> hg init
> cd ..
> mkdir tmp2; cd tmp2
./tmp2
> bar.txt
> hg --repository ../tmp1 add bar.txt 
abort: bar.txt not under root '/tmp/tmp1'

---

Note *: the reason I say "Most of the version control tools that I am familiar with, and all of the modern tools..." is that the tools described in "Boxes, Links, and Parallel Trees: Elements of a Configuration Management System." In Workshop Proceedings of the Software Management Conference. 1989.

have such a feature. Or, rather, had such a feature.

Embarrassingly, I am the author. But, no, really, I did not ask this question for ego gratification - I had forgotten this paper when I started writing this question.

Plus, the tools described in this paper are old and long gone, left behind at an employer years and years ago. And certainly not modern DVCS.

Yes, I know: Brian Berliner disses my paper in his CVS paper. He's wrong and I'm right, but that's another issue. (Brian is happy with the possibility of livelock, I am not.)

Anyway, I am just hoping that this very old concept, of mapping between a repository and files outside the repository - has resurfaced in some modern DVCS tool. Because I would like to use it, as described above.

Answer 1

You can indeed with Git.

Check this answer out Can I store the .git folder outside the files I want tracked?

Basically you create the .git folder wherever you want then set the git core.worktree config to the directory that should be versioned.

There's also lots of information in git help config under the core.worktree section.

Answer 2

ssmith answered the headline request, but reading the motivation makes me want to recommend digging deeper into what git's really capable of. "Full access to internals" isn't some dark corner, it's license to build.

You've spent enough of your life reading manuals that the gitcore tutorial might not take two bags of popcorn to inhale. I'd suggest hunting up git ls-files -simmediately after it introduces git update-index, simply because it's an all-but-complete index dump; and using
git init --template=/dev/null rather than just git init because there's cruft in the default that somewhat obscures the naked simplicity of it all; and doing find -type f liberally as you proceed. To complete the bemusement, pipe the files you see appearing in .git/objects through zlib's examples/zpipe.c and cat -A.

Research effort and all, you can budget one good day to build exactly what you want.

Answer 3

Bazaar has a lightweight checkout mode of operation which only puts enough metadata into the .bzr folder to allow it to talk to the original repo for any operation which requires history data. This will work even for checkouts of remote repos, although those operations will naturally be slower then.