git and svn subrepos

Matt Joiner anacrolix at gmail.com
Tue Jan 12 08:05:12 CST 2010


On Wed, Jan 13, 2010 at 12:47 AM, Augie Fackler <durin42 at gmail.com> wrote:

>
> On Jan 12, 2010, at 12:35 AM, Matt Joiner wrote:
>
> Hi All,
>
> I'd like to know the future roadmap for supporting subrepos of the
> Subversion persuasion. In my/our usage of VCS, externals play a heavy role
> in keeping repository and working copy sizes down, and maintaining internal
> builds and versioning of thirdparty libraries and the like for use by
> various projects. I've been watching
> http://mercurial.selenic.com/wiki/subrepos#To_Do with great interest since
> around the time of the 1.3 release.
>
> I've made two observations with regards to the ability to support the
> "svn:externals" style subrepos:
>
>    - Firstly that svn does versioning, and "basing" on a per directory
>    level, which evidently is not possible in hg. Two possible working arounds
>    would be:
>       - To do something akin to "chroot" when updating;
>       - or maintaining all the directories that one might pick out as
>       svn:external targets as different branches and selecting that branch;
>       - both of which require keeping the entire hg log history locally
>       for each checkout, and furthermore does not version directories at all.
>
> I'm not sure what this has to do with subrepos? Are you wanting to include
> a subdirectory of a Mercurial repository?
>

That's right. Mercurial repositories are always rooted. If they're to be
used in place of previously Subversion externals, this can be an issue for
migration.

>
>
>    - And that secondly, external directories picked from various external
>    repositories, will each require a full hg history folder in the base,
>    destroying the first advantage I listed above. Working copy sizes could
>    become potentially immense, or repository management very complex in trying
>    to juggle library versions etc.
>
> I'm not sure quite what you're asking here either, but in my experience an
> entire hgsubversion clone (with working copy) is often smaller than a single
> svn working copy.
>

This is true, but for a repo with a lot of binaries (such as the thirdparty
compilation repos I mentioned above), we'd have to pull the entire repo, for
each subrepo link against a given hg repository. I'm not sure there's any
way around this one, given that's a core design decision and source of win
for hg.

>
>
> The above observations are of hg repos externaled from an svn working copy
> (and I expect git within hg, and git within svn to be the same), the reverse
> case (svn within hg) is somewhat simpler and requires some intimacy with the
> Subversion bindings.
>
>
> Last I knew, svn:externals had no mechanism for supporting non-Subversion
> VCSes as sources for the externals. That's a feature you'd have to talk to
> them about.
>

Yes I'm drawing parallels, and pointing out that potentially some
functionality I'm not aware of in hg would be required for its being used as
a drop in replacement for existing svn:externals.

>
> Are there any plans, or considerations being made for adding the ability to
> link to svn externals from within hg, and has any discussion occurred
> regarding providing features to ease the use of hg repos within svn
> checkouts?
>
>
> As of about 2 weeks ago, subrepos has svn support, which will be in the
> next release (1.5), which should be available around the beginning of March.
>

Great! Thanks, where can I look for documentation on the implementation thus
far?


>
>
> Regards,
> Matt Joiner.
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20100113/976defda/attachment.htm>


More information about the Mercurial mailing list