Greg Smith <gsm...@gregsmith.com> writes:
> The best way to control the scope creep here is to avoid doing that, and
> instead focus on what you really need from the repo conversion. [...]
> If the goalposts are moved to "every ancient tag/release ever must build
> perfectly and have sane history no matter how nasty its CVS history was",
> history conversion is doomed.
Right. Shall we try to spec out exactly what our conversion
requirements are? Here's a shot:
* Head of each active branch must check out the same as it does from CVS
(modulo $PostgreSQL$ and similar tags, which we've already agreed we can
abandon).
* Each released minor version tag must check out the same as from CVS,
at least back to some specified point (perhaps 7.4.0). I'd really
prefer to insist on that all the way back.
* Each commit message in the CVS history must be retrievable from the
git history, and should correspond to the same file changes. However,
we are okay with git sometimes treating "one" CVS commit as two or more
events with similar messages. (I'm basing this on the behavior of
cvs2cl, which sometimes does that depending on how time-extended the
individual file updates were.) Also, we won't be too picky about
whether the "same" commits on different branches are treated as one
event or multiple events.
Comments? Other considerations?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
