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