Advice re. implementing Mercurial

[David Capps]

> > 
> > > This mostly looks sound, but I'd suggest relaxing the "lint-alike"
> > > tool on every commit requirement. Make it every push instead. One of
> > > the advantages of the distributed model is the separation of "commit
> > > my changes" from "inflict my changes on others". If you want to
> > > allow developers to actually *use* all that history in the
> > > repository, then you want to make it easy to commit what they're
> > > working on (so it doesn't get lost) and update to whatever changeset
> > > they like.
> >
> > Hm, I'll consider that: thanks. With SVN it's scanned on check-in, but
> > of course there's no distinction between commit/push there. The only
> > issue I think might pop up there is that the IBugtraqProvider
> > interface to TortoiseHG allows us to hook into the commit process but
> > (possibly?) not the push process. Although I guess if all we need is a
> > simple continue/don't continue response, the standard HG hooks would
> > probably allow that fine.
> >
> > (Any reason you didn't post this to the public list?)
> >

> Oops, nope. I am just accustomed to other lists where the reply-to
> address *is* the list. Reposting to the list.

Just following on from this, it looks like rebase doesn’t do what we want (since it won’t operate on public changes, and we’re only selecting which changes to move forwards *after* they've been published to our Development tree and QA have had a chance to break them), but graft does seem to do exactly what we want.

I've had one or two instances of possibly-bugs but I'll post those here in a separate thread once I've got proper reproductions on them (assuming this is the right place to post them, anyway).


Cheers,

David Capps