[PATCH] subrepo: look for local pull source first

[Martin Geisler]

Hi again,

I asked my client to explain again why they want full paths in the
.hgsub file. This is what they wrote (with my reply interleaved):

> We have grouped our source code in components. Some of the components
> are reused in different projects. We want to share these
> components/repos rather than duplicating them because this avoids
> overhead and errors.

That makes a lot of sense.

> So the intention is to have these components on one location on the
> server and having multiple "top level" repos on the server referring
> the same subrepo. So on the server the subrepo is outside the top
> level directory but when cloned on the local disc it is then inside
> the top level directory.

This is where I think there is a slight misunderstanding about what is
*possible* and what is *recommended*. It is certainly correct that you
can setup the server so that it has:

  Project-A/.hg/
            .hgsub
               lib/X = http://server/Component-X
  Project-B/.hg/
            .hgsub
               lib/X = http://server/Component-X
               doc/Y = http://server/Component-Y
  Component-X/.hg/
  Component-Y/.hg/

where I've shown the content of the .hgsub file in Project-A and
Project-B. That is the kind of layout you have now with no nested
repositories on the server.

The canonical layout would be:

  Project-A/.hg/
            .hgsub
               lib/X = lib/X
            lib/
                X/.hg/
  Project-B/.hg/
           /.hgsub
               lib/X = lib/X
               doc/Y = doc/Y
            lib/
                X/.hg/
            doc/
                Y/.hg/
  Component-X/.hg/
  Component-Y/.hg/

Here Project-A/lib/X, Project-B/lib/X, *and* Component-X are all related
clones of the same repository.

When Alice in Team-1 works on Project-A, she does

  $ hg clone http://server/Project-A

and works there. When she pushes back, her changesets will end up in
Project-A and Project-A/lib/X on the server. She does

  $ cd Project-A/lib/X
  $ hg push http://server/Component-X

to share her changes to Component-X with other teams. If Bob in Team-2
who works on Project-B, then he can now do

  $ hg clone http://server/Project-B
  $ cd Project-B/lib/X
  $ hg pull http://server/Component-X

to retrieve the changesets pushed by Alice.


Now, you may complain "but the teams will lose synchronization!" and you
will be right to some degree. The "problem" is that Team-1 can work
happily on its lib/X clone of Component-X while Team-2 works on the
other copy of Component-X. At no time is anybody pushing anything to the
shared Component-X.

You can solve this with the standard share extension on the server. What
it does is simple: it behaves as if the .hg folders were symlinked. We
symlink the two clones of Component-X back to the top-level Component-X
repository. So when Alice does

  $ cd Project-A/lib/X
  $ hg push http://server/Component-X

then the changesets show up instantaniously in all three Component-X
clones on the server. In particular, when Bob does

  $ cd Project-B/lib/X
  $ hg pull # no special path

then he gets the changesets Alice just pushed.


-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://aragost.com/en/services/mercurial/blog/