New to Hg - best practices?

Giorgos Keramidas keramida at ceid.upatras.gr
Thu Nov 6 02:00:17 UTC 2008


On Thu, 6 Nov 2008 00:54:59 +0100, "Isaac Jurado" <diptongo at gmail.com> wrote:
>On Wed, Nov 5, 2008 at 11:11 AM, Marcos Scriven <marcos at scriven.org> wrote:
>> 'I have cloned the source for server version x, now give me a clone of
>> the client compatible with this'
>
> Mmmm, a README file?  I know that automation is an implicit goal of
> computer programming, but that feels like it is trying to push it too
> far.

Using a helpful structure in the repository storage area can help.  For
example, if you have a 'stable' client and server repository, you could
upload:

1. an experimental set of repositories at:

    http://hg.hosting.server/experimental/client
    http://hg.hosting.server/experimental/server

2. the stable clones at:

    http://hg.hosting.server/stable/client
    http://hg.hosting.server/stable/server

3. a bugfix-only set of 'stable' clones at:

    http://hg.hosting.server/stable-bugfix/client
    http://hg.hosting.server/stable-bugfix/server

4. a feature-based set of clones, based on 'experimental' at:

    http://hg.hosting.server/exp-zerocopy/client
    http://hg.hosting.server/exp-zerocopy/server

and so on...

There is no perfect setup of clones, but you can design one that seems
convenient to your particular development or release engineering needs :)

PS: The `forest' extension may help someone who wants to pull *both* the
client and server repositories from a particular repository set, i.e. by
making it possible to run commands like:

    hg fclone http://hg.hosting.server/stable-bugfix

(Note the use of the `fclone' instead of `clone' command though.)




More information about the Mercurial mailing list