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.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com