[Python-Dev] Hg: inter-branch workflow

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/21/2011 04:33 PM, Barry Warsaw wrote:
> On Mar 21, 2011, at 07:38 PM, Antoine Pitrou wrote:
> 
>> On Mon, 21 Mar 2011 14:29:54 -0400
>> Barry Warsaw <barry at python.org> wrote:
>>>>
>>>> I don't think many hg users advocate rebase, really. AFAICT the
>>>> Mercurial developers themselves don't seem to use it (they do use mq,
>>>> OTOH).
>>>
>>> I guess that begs the question then. ;)  
>>>
>>> What harm would there be in relaxing the SHOULD in this paragraph to MAY?
>>>
>>> "You should collapse changesets of a single feature or bugfix before pushing
>>> the result to the main repository.
>>
>> Because it's really SHOULD.
>> Apparently some people misunderstand this statement. "collapse
>> changesets of a single feature or bugfix" doesn't mean you must avoid
>> merges. If that's the impression it gives then the wording SHOULD (;-))
>> be changed.
>>
>> The paragraph is aimed at the temptation people may have to commit many
>> changesets for a single feature/bugfix and push them all even though
>> some of them don't leave the source tree in a stable state. What it
>> says is that we don't want work-in-progress changesets in the public
>> history.
>>
>> Again, a better wording is welcome.
> 
> I guess it depends on what "work-in-progress changesets" means. ;)
> 
> If I'm working on a new feature, I am going to make lots of local commits, any
> one of which may not actually be stable.  However, when my work on that
> feature branch completes, I will have a fully functional, stable branch that's
> ready to merge into the default branch.
> 
> As Ben described clearly, with Bazaar, I'd just merge my work-in-progress
> branch to default and be done.  Tools such as bisect and log would ignore all
> my intermediate changes by default, although you *can* drill down into them if
> you want.  But I take it that with our Mercurial workflow, we'd rather all
> those intermediate commits in my local branch were manually collapsed before I
> merge to default.
> 
> My discomfort with this is not just that it changes history, but that it
> throws away valuable information.  Sure, you're not going to care if I fixed a
> typo in NEWS, but you might indeed care that I've addressed the issues you
> raised in your first, second, and third reviews.  Each of those would be
> represented by a changeset in my local line of development, and by a side
> branch in the mainline DAG once my merge is completed.  You might want to dig
> into that sideline to see if indeed I addressed the issues in your second
> review of my code.  If we have to manually collapse changesets at feature
> branch merge time, you can't do that.

Having bisect able to use the intermediate changesets (as an option)
could even make it easier to pinpoint the correct fix for a bug
(assuming people don't routinely make local changes of complete
"guts-on-the-table" messes).


Tres.
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2HuFUACgkQ+gerLs4ltQ6+bACeLETaWB34XZwvJIPYkP3mddrU
JRoAoKCNTnkjFlQe8xXNJdyYUDHoSiFs
=ksyC
-----END PGP SIGNATURE-----