Advice re. implementing Mercurial

[Martin Geisler]

David Capps <dcapps at keystonesoftware.co.uk> writes:

Hi David,

> Graft does appear to, though. Essentially the situation we're thinking
> of is that various developers have pushed up 5 changes over the past
> day or so, merging their changes into head on the Development tree,
> and then QA approves 3 of the 5 to move forwards (and potentially not
> the first 3 changes that were pushed up to Development. Obviously if
> that situation does happen, then happy days, things are trivial).

The traditional way to do this is really more of a take it all or take
nothing approach.

So when a developer begins looking at issue-123, he will create a branch
or a bookmark and make some local commits. He will test things as best
as he can and use 'hg histedit' to modify his commits (reorder them,
improve commits messages, fix bugs introduced in earlier commits). He
will also use 'hg rebase' periodically to keep his local work up to date
with the latest changes on the default branch.

When he is happy, he pushes to some place public where others can review
the commits. At this point the commits become frozen: no more
reordering, no more fixing commit messages, and no more change to pick
just a subset of them.

This is where QA comes into play and tests things. If there are bugs,
the bugs are fixed by adding more commits. If the developer had found
the bugs before pushing, he could have rolled the bugfix into this
original submission (and looked like a super hero writing bug free
code).

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.

> While I haven't tried grafting *large* changesets, my testing worked
> fine using it to pick out arbitrary changes from Development and
> merging them into head on Release.

Like rebase, grafting uses merges to do it's work, so it should be about
as robust as a normal "hg merge". The problem is if you begin skipping
commits: commit 3 might not apply cleanly without commits 1 and 2 (but
that's not a problem with graft, that's an inherent problem when commits
depend on each other).

However, do note that the workflow you suggest will leave you with
orphaned branches in the repositories the developers push to since graft
copies the changes. So the main repository might look nice, but you're
leaving behind cruft elsewhere.

The obsolete markers used by recent versions of Mercurial are
effectively a way to say "please ignore this cruft, the new and better
version is over here".

-- 
Martin Geisler

http://google.com/+MartinGeisler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20150209/292d73d5/attachment.asc>