On 25/08/10 12:36, Heikki Linnakangas wrote:
> On 25/08/10 14:03, Max Bowsher wrote:
>> On 25/08/10 09:18, Magnus Hagander wrote:
>>> On Wed, Aug 25, 2010 at 07:11, Tom Lane<tgl@sss.pgh.pa.us> wrote:
>>>> Robert Haas<robertmhaas@gmail.com> writes:
>>>>> There are also a number of commits that differ in order between the
>>>>> two repos, and an even larger number where commits are duplicated or
>>>>> merged in one repository relative to the other.
>>>>
>>>> I suspect that this is an artifact of the converter trying to merge
>>>> nearby commits into one commit, which it more or less *has* to do for
>>>> sanity since CVS commits aren't atomic. I don't have a problem with
>>>> the concept, but I notice cases where the converted commit has a
>>>> timestamp some minutes later than what the cvs2cl output claims.
>>>> I suspect this is what the converter was using as a cutoff time.
>>>> Would it be possible to make sure that the converted commit is always
>>>> timestamped with the latest individual file update timestamp from the
>>>> included CVS commits?
>>>
>>> I can't comment o nthis part - Michael or Max?
>>
>> cvs2git will try to use the timestamps from the commits, but sometimes
>> the ordering of how revisions and tags relate to each other will
>> actually disagree with the timestamps. In such a case, cvs2git nudges
>> commit timestamps forward in time, to force the defined temporal
>> ordering into consistency with the topological ordering of events.
>
> Hmm, why does it force that consistency? AFAIK git is happy with a
> commit with an older timestamp following a commit with a newer timestamp.
Um. Good point. Why do enforce that?
Michael, do you think anything would break if we just removed the
"ensure monotonicity" code?
Max.