Re: Moving to git
От | Maciek Sakrejda |
---|---|
Тема | Re: Moving to git |
Дата | |
Msg-id | CAH_hXRYOieZfKFg7f8RiRNSXQcy3RODG-CNogpg_iJDWj1QNUQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Moving to git (Craig Ringer <ringerc@ringerc.id.au>) |
Список | pgsql-jdbc |
> To what extent is *perfect* history reproduction required for PgJDBC? Well, it's not about "perfect"--CVS and git are different systems and having the exact same semantics in both is not feasible (e.g., CVS's lack of atomic commits). But in general, this *is* a very good question: what would be the criteria for a transition? E.g., how would we handle something like the keyword expansion discussion that Mike linked? Because ancestry dictates commit hashes, fixing something like this after the fact would be a nightmare. Also, should this be the new go-to repo for *all* history, or is there any reason to keep CVS around for "archival" versions? I believe a git transition should support all history just fine and the old CVS repo could be mothballed (or set up to mirror git), but I could be missing something. Also, how would we validate the transition? E.g., something like passing the (tagged) test suite for each tag (on all supported-at-the-time Java versions?) could be a first step (assuming the suite from CVS passes, but I would hope that's a safe assumption), and probably some source-level diffs against corresponding CVS checkouts. That's easy enough to script and should give us a fair amount of confidence in the move. --- Maciek Sakrejda | System Architect | Truviso 1065 E. Hillsdale Blvd., Suite 215 Foster City, CA 94404 (650) 242-3500 Main www.truviso.com
В списке pgsql-jdbc по дате отправления: