Advice re. implementing Mercurial
Benjamin Fritz
fritzophrenic at gmail.com
Fri Feb 6 16:07:35 UTC 2015
On Friday, February 6, 2015, David Capps <dcapps at keystonesoftware.co.uk>
wrote:
> I wrote:
> > David wrote:
> > > Our desired development process (not all of these steps currently
> > > happen/work well under SVN!):
> > > -We have a number of developers (mostly adding new features) and
> > > support technicians (mostly fixing bugs) committing to source
> > > control
> > > -All commits are required to be flagged with a development or
> > > support ticket reference, and we also run a lint-alike over the
> > > changed files before commit (doesn't prevent commit, just flags
> > > up potential issues to be checked)
> > > -Once a developer has completed a change and pushed it out of
> > > their private tree, QA are required to test and sign off the new
> > > build
> > > -Once a change has been signed off by QA, that change can go into
> > > future releases
> >
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20150206/57ec1164/attachment-0002.html>
More information about the Mercurial
mailing list