Migrating from Clearcase to Mercurial

[Simon King]

On Fri, Dec 16, 2011 at 5:04 PM, Kastner Masilko, Friedrich
<kastner-masilko at at.festo.com> wrote:
>> 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.

For clearcase I wrote a simple program that registered itself as a
handler for special URLs (ccdiff:// and cctree://). Our web interface
used those URLs in its display of files that had been modified on a
branch. Developers could click those links to launch the clearcase
version tree viewer, or their chosen diff tool, which was very
convenient for code review.

For mercurial I intend to do something similar. We will be able to
click a link on the web page to create a local clone already updated
to the appropriate location. I also intend that it be able to clone a
local repository first, and then pull only the latest changes from the
server, to speed up clone time.

>
>> 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.

This is certainly an option. Our build machines will be cloning the
central repo in order to build the software, so the local {rev} values
in the build clone will potentially be different to those on the
server, but that may not be an issue.

> 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".

I hadn't realised that "hg identify" could operate on URLs - that
could come in very handy, and as you say, make local tags on the
server a useful mechanism. I suppose this could actually form the
basis of the database of build IDs as suggested by Martin.

>
>> 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.
>

Yes, they have been very helpful. Thanks a lot,

Simon