[GSoC] Adding svn:externals support to hgsubversion

[Daniel Tang]

On Wed, Apr 8, 2009 at 15:37, Patrick Mézard <pmezard at gmail.com> wrote:
> Two remarks:
>
> 1- it is not necessary to implement svn:externals as fully converted mercurial repositories referenced by revision identifiers. My initial plan was to implement hooks on Mercurial update command (or as an explicit hgsubversion command to avoid useless updates by rebasing code for instance) which would update the relevant externals based on the externals state in the from and to revisions. The obvious downside is it requires the referenced subversion repository to be available. The advantage is it does not require any support for subrepos, and it might even be possible to use the svn client to do that. Also it might be easier to implement, and looks like a short path to make hgsubversion usable at work by people like me.
>

True, it is probably sufficient if only the revisions stored are the
ones specified by externals. My reasoning for wanting to implement
this on top of sub-repos was that the resulting repository (or set of
repositories) would be able to be cloned by any Mercurial client that
supported sub-repos (aka treated "normally"). This would probably be
more helpful in the case that you use Mercurial to interface to a
Subversion repo that you don't have commit access to, but I don't see
it as being particularly helpful in your case. I'm not entirely tied
to the idea of implementing externals on top of sub-repos, but I feel
like it is a more complete solution.

> 2- Again, converting *all* revisions (or all starting at a rev) of externals project is not necessary. Assuming only externals with explicit target revisions are handled (the others are brain damaged anyway, even svn people recognize that), externals are really a subset in term and revision of the referenced project. In my experience, it is a sparse subset.
>

I figured that explicit revision numbers were the most common, but I
feel uncomfortable leaving the other options out. The naive case where
all revisions are copied would probably be the easiest implementation
(assuming sub-repos), since it would really just be cloning another
repository and adding sufficient information to make it a sub-repo.

Dan