Hi,
Quoting "Marc G. Fournier" <scra...@hub.org>:
Actually, I have done that on at least one of the 8.x tags too, so
if that is it, more then those two tags should be causing issues ...
Not *every* such issue causes problems. An example that's perfectly fine:
cvs commit -m "first commit" fileA
cvs tag TEST filA
cvs commit -m "second commit" fileB
cvs tag TEST fileB
In such a situation, a converter can easily "push-down" the tag TEST
to the second commit, because fileA is the same (in that revision) as
after the first commit. After all, the results in the RCS files are
exactly the same as if you did the following:
cvs commit -m "first commit" fileA
cvs commit -m "second commit" fileB
cvs tag TEST fileA fileB
A converter can't possibly distinguish these two.
However, if both files get committed the second time, but only one
gets tagged, it gets problematic (always assuming the commit actually
changes the file):
cvs commit -m "first commit" fileA
cvs tag TEST filA
cvs commit -m "second commit" fileA fileB
cvs tag TEST fileB
That's perfectly valid from CVS's point of view, unwanted for the
Postgres repository and hard to handle for a converter to git (or
mercurial, monotone, etc..), because the tag TEST is on the first
commit for fileA but on the second for fileB, while both of fileA and
fileB differ between the commits.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
