fedora considering hg

[Giorgos Keramidas]

On 2006-11-17 15:45, Jesse Keating <jkeating at redhat.com> wrote:
>On Friday 17 November 2006 15:34, Benoit Boissinot wrote:
>> The preferred way to handle branch is to clone the repo, this operation
>> is fast (it's just a "cp -al + hg update"), if you really want to create
>> a in-repo branch, it's even faster (works only with the development
>> version currently).
>
> While a clone really is the best way, when working with a central repo
> (yes we are loonies that still want to do this) a local clone doesn't
> stay on the server and isn't easily shared with other people (or used by
> say a build system that would pull from the central repo).  This is why
> an inrepo branch or set of branches is important.

You can always use the 'central repository area' in a way that lets you
have:

    ssh://keramida@central.host//repos/release/foo-1.0
    ssh://keramida@central.host//repos/release/foo-1.1
    ssh://keramida@central.host//repos/release/foo-1.2
    ssh://keramida@central.host//repos/trunk/foo
    ssh://keramida@central.host//repos/user/keramida/foo-1.0-extra
    ssh://keramida@central.host//repos/user/keramida/foo-1.1-extra
    ssh://keramida@central.host//repos/user/keramida/foo-1.2-extra

With proper access controls for the filesystem space under `/repos/user',
you can set things up so that:

    * When user `keramida' commits in his local clone of the
      `/repos/user/keramida/foo-1.2-extra' repository, changesets
      are autopushed to the central host (i.e. using a hook).

    * The build system can use its own clone of a repository from the
      `/repos/user/keramida/*' repository collection to check out and build
      snapshots (or `hg archive' to check out unversioned copies of a
      particular snapshot).

You don't even have to cram everything inside `/repos', but you can set
things up so that `official' branches are kept in there, but personal
developer branches/clones are kept in each user's home directory of the
`central.host' server, and forget all about the `/repos/user/${USER}'
stuff.

This will, admittedly, take some work setting up, but you have all the
freedom you want in the way you design a `/repos' tree of workspaces.

With a distributed SCM, you can still use a collection of branches which
are considered ``a central repository'', but you are more than free to also
use a hierarchical organization of `workspaces'.  Some of these can be free
for all developers to push, some may be locked down for particular
developers, some of them may be locked down for all _except_ particular
developers, and some may be locked for everyone (snapshots of older
releases, perhaps?).

It's up to the release engineering team to design some sort of repository
organization that maps well with the particular ``work flow'' you are going
to use.  It helps, in this case, to think of repositories/branches/clones
are `gates', through which the source code changesets have to flow.
Assigning a particular type to each `gate' (i.e. xdevelopment', `testing',
`prerelease', `release', `tag', or anything else) is something not imposed
upon everyone by the way Mercurial works.  You can use the tool (Mercurial)
and its features to design the policy (work flow).

- Giorgos