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.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
