Re: PostgreSQL Developer meeting minutes up
От | Markus Wanner |
---|---|
Тема | Re: PostgreSQL Developer meeting minutes up |
Дата | |
Msg-id | 20090528092518.19705813rymuy3j2@mail.bluegap.ch обсуждение исходный текст |
Ответ на | Re: PostgreSQL Developer meeting minutes up ("Marc G. Fournier" <scrappy@hub.org>) |
Список | pgsql-hackers |
Hi, Quoting "Marc G. Fournier" <scrappy@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
В списке pgsql-hackers по дате отправления: