Distributed SCM and branching a sub-directory ?

I am considering switching from SVN to a distributed SCM for my personal stuff. I had a look at git and mercurial, but neither really support branching a sub-directory:

Often, I am working on a big private project, and, while working on a sub-project (stored inside the project’s repository), I’d like to share that sub-project with others. So there are actually two problems:

  • being able to checkout/branch/clone a sub-directory
  • possibility to control access on a per-directory basis

SVN only partially meets my needs with that (it’s possible to checkout a sub-directory directly, for example with svn co svn://svn.debian.org/svn/pkg-ruby-extras/tools/ruby-pkg-tools). I think that it’s possible to do fine-grained access control
using libapache2-svn, but I haven’t tried yet.

It seems that mercurial can do that, using the forest extension. But you have to convert the specific directory into a repository, with a complex step to keep the history.

Amongst the distributed SCM, is there one that supports that ? (at least the sub-directory branching part)

8 thoughts on “Distributed SCM and branching a sub-directory ?

  1. I think with “changeset” based systems really branching off subdirectories is hard. you would need to split the changeset if it has changes inside and outside. And normal distributed scms a) use immutable changesets, b) copy all changesets for the relevant timespan on cloneing/checkout/….
    So keeping parts of the tree private in distributed scms is not easy to get.

  2. I think that it’s possible to do fine-grained access control
    using libapache2-svn, but I haven’t tried yet.

    Indeed it is, but it causes problems with add-ons :(

    I use authz, which works fine for svn:// access, giving you directory level access control via svn commands, or web access.

    However, many(most?) of the web front ends (websvn, viewvc) subterfuge things such that authz access control is bypassed :(

    trac, however works fine !

  3. Git’s new “submodule” support would let you have the same type of structure as hg’s forest extension. You could use git-split to split out the history of a submodule, and with some minor enhancements to git-split, it could also rewrite the history of the rest of the repo to reference the submodule.

  4. I would second SVK, particularly if you are already using Subversion. It really is a very nice tool.

Comments are closed.