hg, git, fossil, ...

Tim Chase python.list at tim.thechases.com
Thu Aug 28 10:56:05 EDT 2014


On 2014-08-28 08:58, Marko Rauhamaa wrote:
> The main problem with hg (and git) is the way cherrypicking is done.
> 
> See these graphics:
> 
>  [1]   Product-Ver1
>             |
>             | bugfix
>             |
>             V          feature development
>        Product-Ver1' ----------------------> Product-Ver2'
> 
>                        feature development
>  [2]   Product-Ver1 -----------------------> Product-Ver2
>                                                   |
>                                                   | bugfix
>                                                   |
>                            cherry-picking         V
>        Product-Ver1' <---------------------- Product-Ver2'
> 
> 
> My beef is this: The starting point and end result of [1] and [2] is
> identical. The version histories of Product-Ver1' and Product-Ver2'
> should usually also be identical. In hg and git, they are not. In
> CVS, they are not. In SVN, they are not.
> 
> In TeamWare (and bitkeeper?), the version histories are identical.

I'm not sure how you arrive at the conclusion that git/hg/cvs/svn
are wrong and TeamWare et al. are correct.  If you diff the two,
you'll find that the end result is the same, but the history is
different.  At least git/hg/bzr ensure that the historical tree that
I have and the historical tree that you have are identical.  In your
description, their histories are not.  This ensures that when I speak
about "the ancestor of Product-Ver2", we're both talking about the
same thing.  In #1, that's Product-Ver1' while in #2, that's
Product-Ver2.

-tkc






More information about the Python-list mailing list