Persistent branches as side-by-side copies within one repository

[Mike Meyer]

On Fri, 01 Oct 2010 15:23:16 +0200
Martin Geisler <mg at aragost.com> wrote:
> Mike Meyer <mwm at mired.org> writes:
> > On Thu, 30 Sep 2010 16:44:15 +0200
> > Carsten Orthbandt <carsten.orthbandt at googlemail.com> wrote:
> >> Again, using multiple repos for this isn’t feasible since I’d end up
> >> with 50+ repositories making workplace maintenance impossible.
> >
> > In this case, you really need tools that do the workspace management
> > for you. I've not tried that with mercurial yet, but have done it for
> > subversion. A single project could depend on anywhere from 50 to over
> > 200 different libraries, with the version of libraries changing
> > depending on the project and version of the project. We used a file
> > that described all the libraries used by the project, and a tool that
> > would make sure that the correct version of every library was checked
> > out in the workspace and likewise dealt with checking in changes to a
> > library and the project description file to make sure that your builds
> > were properly reproducible. I think subrepos have all the facilities
> > for this, but haven't really played with them to verify that.
> 
> Subrepositories do support exactly this use case: you have a .hgsub file
> which declares the dependencies:
> 
>   libs/foo = http://libfoo.org/hg/foo
>   libs/bar = libs/bar
> 
> Here the foo lib is cloned from a fixed location and the bar lib is
> cloned from a location relative to the top-level repo.
> 
> There is also a .hgsubstate file (managed by Mercurial) that records the
> exact revision of each subrepo used when you make a top-level commit.
> 
> When you update the top-level working copy the .hgsubstate file is read
> and the subrepos are updated to their correct versions.

I think the next requirement is where thing get controversial. If I
commit at the top level, it should commit any changes to subrepos
*first*, so the .hgsubstate file correctly reflects the version used
for the build in the current workspace when you check it in.

Do push and pull also pay attention to this? If I push changes to the
top level, changes to .hgsubstate that refer to revisions that aren't
worth anything, so a push needs to push subrepos as well. And of
course, ditto for pull.

Or maybe I just need a pointer to the documentation.

   Thanks,
   <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org