On Wed, Jun 25, 2008 at 7:13 PM, Sylvain Beucler <[EMAIL PROTECTED]> wrote: > Hey, >
Sorry for the delay (I still have another message to answer). > Another thing I think of is: code linked repositories. > > For example, if a repository is a branch of another repository, it can > be optimized (see "forks" in git.or.gz). This saves space. Does > Mercurial has it too? > I'm not sure what you mean. I am unable to find anything related to "forks" in git.or.cz. Mercurial has branches (named branches) that, as far as I can read, are like git branches. These are branches in the same directory repository and you can update and merge between branches easily. Another option for branching is to clone a repository in a separate directory and start commiting there. > bzr also tend to have a central '.bzr' repository and subrepositories > that automatically look for ../.bzr or ../../.bzr, etc. (at least > that's how CVS repos are converted to). > In Mercurial there is the forest extension: "The Forest extension allows operations on trees with nested Mercurial repositories, called forests. Those to some degree correspond to multi-project CVS/Svn/... repositories." http://www.selenic.com/mercurial/wiki/index.cgi/ForestExtension > So these relationships could be saved in the database so that the > backend can take advantage of them for efficiency (instead of having > people duplicate all of the repository each time an external branch is > created). Sorry, I don't see it :-(. I see how branches save space as there is only one reposority and git/Mercurial know how to handle this. For these kind of branches there is no need to maintain anything in the database as the SCM does it for you. If you need separate repository branches, then we need to store them in the database as part of the multiple repository feature. I think I need a little bit more of explanation on your e-mail :-). Aleix
