Is there any distributed revision control system that supports partial checkout/clone?

As for version 1.6, it is not possible to make a so-called "narrow clone" with Mercurial, that is, a clone where you only retrieve data for a specific sub-directory. We call it a "shallow clone" when you only retrieve part of the history, say, the last 100 revisions As you say, there is nothing in the common DAG-based history model that excludes this feature and we have been working on it. Peter Arrenbrecht, a Mercurial contributor, as implemented two different approaches for narrow clones, but neither approach has been merged yet.

There is a Google Summer of Code student working on shallow clones this year, so there is hope that feature will appear soonish Btw, you can of course split an existing Mercurial repository into pieces where each smaller repository only has the history for a specific sub-directory of the original repository. The convert extension is the tool for this. Each of the smaller repositories will be unrelated to the bigger repository, though -- the tricky part is to make the splitting seamless so that the changesets keep their identities.

As for version 1.6, it is not possible to make a so-called "narrow clone" with Mercurial, that is, a clone where you only retrieve data for a specific sub-directory. We call it a "shallow clone" when you only retrieve part of the history, say, the last 100 revisions. As you say, there is nothing in the common DAG-based history model that excludes this feature and we have been working on it.

Peter Arrenbrecht, a Mercurial contributor, as implemented two different approaches for narrow clones, but neither approach has been merged yet. There is a Google Summer of Code student working on shallow clones this year, so there is hope that feature will appear soonish. Btw, you can of course split an existing Mercurial repository into pieces where each smaller repository only has the history for a specific sub-directory of the original repository.

The convert extension is the tool for this. Each of the smaller repositories will be unrelated to the bigger repository, though -- the tricky part is to make the splitting seamless so that the changesets keep their identities.

At least in Git, the DAG representing the repository history applies to the whole repository, not just a single file. Each commit object points to a "tree" object which represents the entire state of the repository at that time. Git 1.7 supports "sparse checkouts", which allow you to restrict the size of your working copy.

The entire repository data is still cloned, however.

Ok this answers my question at least for git. I wonder whether every distributed rcs is designed this way or if you can have a design that allows splitting and joining of repositories. – Jakob Jun 23 '10 at 19:47.

In bazaar you can split and join parts of a repository. The split-command allows you to split a repository into multiple repositories. The join-command allows you to merge repositories.

Both keep the history. However this isn't as handy a the SVN-model, where you can checkout/commit for a sub-tree. There's a planned feature called Nested-Trees for bazaar, which maybe would allow partial checkouts.

Hm, I tried split and join but they keep the whole history instead of only the history of a subset of the repository. The fast-import plugin (launchpad. Net/bzr-fastimport) seems to do the job but afterwards I cannot merge updates from the source repository which I split from.

I hope that nested trees is not vaporware. – Jakob Jun 23 '10 at 19:43 I'm not 100%, but bazaar has only global versions and history. Each change-set applies to the whole repository.So when you split, the whole history applies also for the sub-directory.

Thats why the whole history is still there after the split. Except that some entries don't have any effect. Nested-Trees: I don't know.

Let's hope it's not vaporware. – Gamlor Jun 24 '10 at 12:33.

There's a subtree module for git, allowing you to split off a portion of a repository into a new repo and then merge changes to/from the original and the subtree. Here's its readme on github: github.com/apenwarr/git-subtree/blob/mas....

I hope one of these RCS's will add narrow clone capability. My understanding is that the architecture of GIT (changes/moves tracked across the whole repo) makes this very difficult. Bazaar prides itself on supporting many different types of workflows.

Lack of narrow clone capability prohibits an SVN/CVS like workflow in bzr/hg/git, so I'm hoping they'll be motivated to find some way to do this. New features shouldn't come at the expense of basic functionality, like the ability to fetch a single file/directory from the repo. The "distributed" feature of modern rcs's is "cool," but in my opinion discourages good development practices (frequent merges / continuous integration).

These new RCS's all seem to lack very basic functionality. Even SVN without real branching/tagging support seemed like a step backwards from CVS imo.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.