cvs to git migration - keywords
in [PgSql]
|
From: Dave Page on 7 Jul 2010 05:05 On Wed, Jul 7, 2010 at 10:01 AM, Magnus Hagander <magnus(a)hagander.net> wrote: > 1) We can migrate the repository with the keywords, and then make one big > commit just after (or before, that doesn't make a difference) removing > them. In this case, backbranches and tags look exactly like they do > now, but it also means if you do "git diff" between old versions, the > keywords will show up there. > > 2) We can filter out that row during the conversion, so they look like > they never existed.That means that if you check out 7.4.3 or whatever > fro git, it will look like the keyword lines never existed. Since > they're in comments it shouldn''t affect functionality, but it does mean > that we are *not* keeping history unmodified. The advantage is that > "git diff" on and between old revision won't include the keyword > changes, of course. > > #1 is most likely the easiest one. +1 for #1. Changing history and the resulting possibility of becoming one's own grandfather always makes me nervous. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Andrew Dunstan on 7 Jul 2010 10:23 Magnus Hagander wrote: > In the previous discussions of how to migrate from cvs to git, we've > all agreed we should kill the keyword expansion that we have now. I > don't think, however, that we ever decided what to do with the *old* > keywords. We did say we want to be able to reproduce backbranches/tags > *identically* to what they are now, which indicates we need to leave > the keywords in for those. That has other drawbacks, though. > > The way I see it, we have two ways to do it: > > > 1) We can migrate the repository with the keywords, and then make one big > commit just after (or before, that doesn't make a difference) removing > them. In this case, backbranches and tags look exactly like they do > now, but it also means if you do "git diff" between old versions, the > keywords will show up there. > I don't think this would be a terrible tragedy. Import, remove keyword lines on live branches, commit. That's what I'd do. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Dave Page on 7 Jul 2010 10:43 On Wed, Jul 7, 2010 at 3:40 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > One point that isn't completely clear from Magnus' description is > whether we should remove the $PostgreSQL$ lines from the HEAD branch > only, or from the still-active back branches as well. �I vote for the > latter --- that is, if you pull a historical version of some file > from the archives, you should see the appropriate $PostgreSQL$ line, > but we won't have them in the source files for any future minor > release. �The reason for this is that otherwise there will be files > floating around that claim to be CVS version x.y.z, but actually are > different from that, because of back-patching activity after the git > transition. �That seems like a recipe for huge confusion in itself. Agreed. They should be removed from the active back branches. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 7 Jul 2010 10:57 Robert Haas <robertmhaas(a)gmail.com> writes: > So what happens right now using the existing git repository is that > the $PostgeSQL$ tags are there, but they're unexpanded. They just say > $PostgreSQL$ rather than $PostgreSQL: tgl blah blah$. Really? All of them? Seems like that would have taken some intentional processing somewhere. If we could make the conversion work like that (rather than removing the whole line) it would negate my line-number-change argument, which might mean that files pulled from the repository would be "close enough" to their actual historical form that no one would mind. It's still a judgment call though. On balance I think I'd rather adopt the simple rule that historical file states in the git repository should match what you would have gotten from the cvs repository. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tim Landscheidt on 7 Jul 2010 11:25 Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >>> 1) We can migrate the repository with the keywords, and then make one big >>> commit just after (or before, that doesn't make a difference) removing >>> them. In this case, backbranches and tags look exactly like they do >>> now, but it also means if you do "git diff" between old versions, the >>> keywords will show up there. >> +1 for #1. Changing history and the resulting possibility of becoming >> one's own grandfather always makes me nervous. > Yeah. One concrete problem with removing the $PostgreSQL$ lines is it > will affect line numbering everywhere. Yeah, it's only off-by-one, but > there could still be confusion. > [...] If not the whole line was removed, but only the "$PostgreSQL$" part, the numbering should stay the same. I guess it would otherwise be challenging to automatically not only delete the "$PostgreSQL$" line, but also leading and/or trailing empty (comment) lines, and not mess up. Tim -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
|
Next
|
Last
Pages: 1 2 3 4 Prev: [HACKERS] cvs to git migration - keywords Next: Python Interface Hacking |