Migrating from Clearcase to Mercurial

Fri Dec 16 11:04:03 CST 2011

> From: mercurial-bounces at selenic.com [mailto:mercurial-bounces at selenic.com] On Behalf Of Simon King
>
> For the branching behaviour, I am heeding the warning on
> http://mercurial.selenic.com/wiki/StandardBranching and not using
> named branches for every change. Instead, I am going to create a new
> server-side clone whenever a developer wants to start a new piece of
> work. He will push his changes to that clone where they can be
> reviewed. Once the review is complete (and as long as the clone is
> fully merged up with the main repository), the server will log the
> outgoing changesets, then push them from the branch repo to the main
> repo. The branch repo will probably then be deleted to save space on
> the server.

So you are essentially using anonymous branching and create a naming for it by means of the URL you push to. I think in your case, bookmarks could come handy, since it kind of shifts the naming from URL to the bookmark. So your users won't have to change the remote setting (the URL they push to) with every branch, but can instead push to the same remote with different bookmark "target". I.e., instead of

"hg push http://myserver/project/branch"

they could do it by something like

"hg push http://myserver/project -B branch"

Of course this is in case of using >=1.7 versions. AFAIK, pushable bookmarks were introduced there - as extension first, then built-in.

The drawback here would be a possible confusion if a user pulls without specifying a bookmark... he'd get all branches and could get lost. Your cloning approach gets rid of this, but comes with the disadvantage of having to pull from many different remotes, if you want all branches or just take a look at a given branch's progress.

> I'm less confident about how to deal with the tagging. From a
> technical point of view, it's not nearly as important to tag every
> merged branch, because the changeset ID is a perfectly good unique
> identifier. But socially, I don't think we can do without those
> incrementing build IDs; people are too used to referring to builds by
> their number, and understanding that build A is more recent than build
> B simply because it has a higher number. (We could store build IDs
> outside of mercurial, but then developers can't use them with commands
> like 'hg merge' and 'hg update')

If I understood you right, your workflow already consists of one "central" server-repo. You could use the (somewhat standard) "{rev}:{node|short}" template of this repository, then. It would give you e.g. 123:a433f522ecdd , with the first part showing a incremental number for "sense of metric", and the second part for unique identification.
Forget about constructing a unique ID that fulfils both metric and distribution properties for a DAG. While it is possible (Goedel comes to mind), it is somewhat hard to do and IMHO not worth the trouble. Just give your users something for their peace of mind, but always note the non-distribution of the incremental number together with the uniqueness of the hash-code part.

If you need a customer-friendly (or, let's put it better: marketing-friendly) label for the version, you can use local tags on the server. AFAIK, you don't need to have a working copy for that, "hg tag --local --rev <rev> <text>" just puts a hashcode/text line into .hg/localtags . Not pull/push-able, but you can always run "hg identify --rev <text> <URL>" against the server to identify the corresponding revision.

So to summarize, your "outsiders" would communicate with you like "Version V1.2.3.whatnot-beta has a bug", but your "insiders" would identify this label as 123:a433f522ecdd, know that 123 is newer than 112, and communicate to each other to check version "a433f5". The hash-code is then important while reviewing, gets an additional metric with the incremental number on being built by CI, and becomes customer-friendly with the hand-made tagging "Version V1.2.3.nowevenbetter-alpha".

> Thanks for any suggestions you can give (even "don't be so stupid,
> that's a ridiculous way to work!"),

You are definitely not stupid and seem to have put quite some thinking in it already. I hope my comments are of help.

regards,
Fritz

Development Software Systems
Festo Gesellschaft m.b.H.
Linzer Strasse 227
Austria - 1140 Wien

Firmenbuch Wien
FN 38435y
UID: ATU14650108

Tel: +43(1)91075-198
Fax: +43(1)91075-282
www.festo.at

Der Inhalt dieses E-Mails ist ausschliesslich fuer den bezeichneten Adressaten bestimmt. Jede Form der Kenntnisnahme,
Veroeffentlichung, Vervielfaeltigung oder Weitergabe des Inhalts dieses E-Mails durch unberechtigte Dritte ist unzulaessig. Wir
bitten Sie, sich mit dem Absender des E-Mails in Verbindung zu setzen, falls Sie nicht der Adressat dieses E-Mails sind und das
Material von Ihrem Computer zu loeschen. 

This e-mail and any attachments are confidential and intended solely for the addressee. The perusal, publication, copying or
dissemination of the contents of this e-mail by unauthorised third parties is prohibited. If you are not the intended recipient of this
e-mail, please delete it and immediately notify the sender.