Using bookmarks in Mercurial itself

[Peter Arrenbrecht]

On Fri, Jun 17, 2011 at 1:08 PM, Martin Geisler <mg at aragost.com> wrote:
> Idan Kamara <idankk86 at gmail.com> writes:
>
>> 2011/6/15 Martin Geisler <mg at aragost.com>:
>>> By the way, maybe we should begin using some bookmarks in Mercurial
>>> itself: Henrik and I could push the patches for abandoned changesets
>>> as a branch with a bookmark and you and others could give much better
>>> and faster feedback in the form of commits instead of just chatting
>>> here.
>>
>> How will that last bit you said work exactly?
>
> (half-joking) Nobody knows since we've never tried to use Mercurial as a
> DVCS before... :-)
>
>> Other devs will simply commit fixes to other devs work? What if
>> there's a disagreement?
>
> We'll discuss things -- of course. I just often feel that we could be
> more productive if we cut down on the round-trip time. So instead of me
> saying: "there is a typo here", or "this doesn't work, here is how you
> should do it", then I can go in and make a new commit with the changes.
>
> Even if you are not concerned about the round-trip times, then I think
> this would have another and even bigger benefit: we could begin *working
> together* on features. You have probably noticed this yourself: the
> development of Mercurial really consists of a lot of 1-man efforts.
>
>> I thought the whole point of sending patches to the list is to have a
>> discussion and let others review -before- committing stuff.
>
> That is the purpose and the result is a pretty nice history in
> Mercurial: very linear and very good commits.
>
> But don't you also think that it is strange that we have such a fine
> tool available and then we're still hesitant to commit things for real?
>
> It's of course just a gut feeling, but I feel that a DVCS should allow
> us to commit and experiment more freely than we do today.

True. One way to do this right now is to collaborate on dedicated
clones where you can basically work however you like. Just publish a
repo on bitbucket or wherever. This way there is no danger of stuff
that might eventually be abandoned already hitting the main repos.

Then, when everything looks fine, you submit the result as a patch to
the list. Of course, you'll likely want to submit multiple patches for
any substantial effort. There you have two choices: have someone rip
the change back apart once it looks good overall, or else develop it
as incremental patches from the start. The latter is how pbranch was
born - it targets exactly this need. ;)

>> Also, won't it add a lot of 'noise'? i.e.:
>>
>> commit 1: initial feature implementation
>> commit 2: fix 1
>> commit 3: fix 2
>> ...
>> commit N: last fix
>> <merge to default>
>>
>> instead of:
>>
>> patches: implementation here
>> <sending to the list>
>> <getting feedback, fixing, refreshing patches>
>> <repeat 2 of the above until finished>
>> <push to crew>
>> <merge to default>
>
> It would add more noise to the history, naturally. It would be a very
> good idea to still ensure that the test suite run with no errors after
> every commit.
>
> Part of such a workflow would be to put more emphasis on merge commits.
> I talked with Sune yesterday about just such a feature. Imagine if you
> could do
>
>  hg update crew-tip
>  hg merge --hide-second-parent feature-x
>  hg commit
>
> and then write a proper commit message. The merge changeset would have a
> bit set in the extra data that tells Mercurial to hide the changesets
> that were merged in (we can hide changesets now). You would then write a
> nice merge commit message that explains what feature you're merging in.
>
> That should help with the problem of noise: even if Henrik and I have 30
> changesets on a branch to implement abandoned changesets, then you'll by
> default only see the merge changeset unless you use 'hg log --hidden'.
>
> (I put the flag goes on the merge command since this feature would need
> to allow merges-with-ancestor in case nothing new has happened on the
> main branch when you merge in your feature.)

+1. One might then go and make bisect ignore hidden csets (either on
demand or by default) so one has the option of reducing round-trip
time even more by not mandating passing tests for every commit
(depending on project policy of course - I'm not suggesting hg itself
should adopt this relaxation).

-parren