hg, git, fossil, ...
Ned Batchelder
ned at nedbatchelder.com
Thu Aug 28 11:39:07 EDT 2014
On 8/28/14 1:58 AM, 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 feel like I am misunderstanding you. My summary of what you just said
is, "I have two scenarios where my code went through different sequences
of changes to end up with the same content. I expect both of those
paths will show the same history." That sounds nonsensical to me, so I
must be misunderstanding you. The path the file followed (that is, the
sequence of changes that made the file what it is), *is* the history of
the file. If two different sequences of changes can result in the same
history, then one (or both!) of the histories are "wrong" in that they
don't accurately reflect the sequence of changes that happened.
Maybe you can elaborate?
--
Ned Batchelder, http://nedbatchelder.com
More information about the Python-list
mailing list