Re: PostgreSQL Developer meeting minutes up - Mailing list pgsql-hackers

From Markus Wanner
Subject Re: PostgreSQL Developer meeting minutes up
Date
Msg-id 20090602134831.186767ksvmsgj8gf@mail.bluegap.ch
Whole thread Raw
In response to Re: PostgreSQL Developer meeting minutes up  (Marko Kreen <markokr@gmail.com>)
Responses Re: PostgreSQL Developer meeting minutes up  (Marko Kreen <markokr@gmail.com>)
List pgsql-hackers
Hi,

Quoting "Marko Kreen" <markokr@gmail.com>:
> Btw this conversion seems broken as it contains random merge commits.

Well, that's a feature, not a bug ;-)

When a commit adds a file to the master *and* then to the branch as
well, cvs2git prefers to represent this as a merge from the master
branch, instead of adding the file twice, once on the master and once
on the branch.

This way the target VCS knows it's the *same* file, originating from
one single commit. This may be important for later merges - otherwise
you may suddenly end up with duplicated files after a merge, because
the VCS doesn't know they are in fact the same.

(Okay, git assumes two files to have the same origin/history as long
as they have the same filename. But just rename one of the two, and
you are have the same troubles, again).

Also note that these situations occur rather frequently in the
Postgres CVS repository. Every back-patch which adds files ends up as
a merge. (One could even argue that in the perfect conversion *all*
back-patches should be represented as merges, rather than as separate
commits).

> parsecvs managed to do it without them.

Now, I'm not calling it broken, but cvs2git's output is arguably
better in that regard.

As you certainly see by now, conversion from CVS is neither simple nor
unambiguous.

Regards

Markus Wanner


pgsql-hackers by date:

Previous
From: Marko Kreen
Date:
Subject: Re: PostgreSQL Developer meeting minutes up
Next
From: "Markus Wanner"
Date:
Subject: Re: PostgreSQL Developer meeting minutes up