Re: [Savannah-hackers-public] support for repository(ies) contact/description

[Aleix Conchillo Flaqué]

On Wed, Jun 25, 2008 at 7:13 PM, Sylvain Beucler <address@hidden> 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