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<t...@sss.pgh.pa.us> wrote: >>>> Robert Haas<robertmh...@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.
signature.asc
Description: OpenPGP digital signature