Advice re. implementing Mercurial

[David Capps]

-----Original Message-----
From: Martin Geisler [mailto:martin at geisler.net] 
Sent: 09 February 2015 10:45

> The traditional way to do this is really more of a take it all or take nothing approach.
>
>...
>
> This process goes on until QA is happy with the end result, namely the diff from the very first commit to the last commit on this branch. They then merge the code into the default branch -- so that other developers can see the work and rebase their local branches on top of it.
>
> Any other approach is bound to create extra cleanup steps. If I push 5 commits and you graft 3 of them, well then I need to somehow get rid of the two commits you > didn't pick. As I write below, the evolve extension helps here.
>
> Everybody asks how to merge only commit 3 out of 5 commits and the answer is "don't do that" since grafting it creates extra work. Try instead to make developers > very conscious about not mixing different lines of work together into one branch. Put refactorings into a different branch than bugfixes and features.

Thanks for the comments ... the problem is that I don't think all-or-nothing will work for us; if we released less frequently, perhaps, but as it is we release an updated version every[0] week[1]. So we really can't be in a position where we've pushed 15 bugfixes into Development and none of them go out until all 15 pass QA - the option has to be there for QA to approve 11 of the fixes and hold back the other 4 for a future release.  If we separated bugfixes into urgent / high / low priority branches I suppose that would potentially let us get around that - bugs already get classified on importance, of course - but I think we'd still have the same issue when a bug changed priority?

The same also applies to features, to some extent - we could quite easily have 5 new features land in Development in fairly short order, all of which were paid for by [potentially different] customers, and holding up 4 of them because the 5th failed QA *might* not be acceptable (obviously if we don't have customers waiting urgently for any of the 5, then great - we probably can wait until all 5 pass QA and merge them all at once).

I can see graft is going to give us extra clean up work, but I don't currently see any way around that ... I think we'll certainly *aim* to approve changes without grafting, because why buy ourselves extra work if it's not necessary - but it looks like there's always going to be situations where we need to graft changes in.


Cheers,

--
David Capps


[0]Well, most, not strictly every single week

[1] and unfortunately we probably can't get away from that - we sell software into small businesses and it's not uncommon for them to tell us things like "our supplier has changed their EDI file format without any warning! We need the new format integrated by next week!", or similar. In an ideal world we'd say "get a better supplier", but in practice, the answer has to be "well, that's chargeable work, but we'll get right on it and have a new version out shortly."