cvs to git migration - keywords
in [PgSql]
|
From: Magnus Hagander on 7 Jul 2010 14:34 On Wed, Jul 7, 2010 at 20:31, Andrew Dunstan <andrew(a)dunslane.net> wrote: > > > Robert Haas wrote: >> >> 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$. �I'm all in >> favor of removing them, but it would be nice if we could avoid >> cluttering the old changesets with useless changes to the keyword >> expansions. >> >> >> > > Personally I favor leaving the expanded keywords in what we import, so that > there's an exact mapping between what's in the final CVS repo and what's in > the inital git repo, and then removing them entirely. I don't see that > having old keyword expansions in the historical changesets is a bid deal. > Nobody is going to base patches on them (I hope). This is my general feeling as well. If there are outstanding patches they will need to be merged, but actually getting a conflict there would require that someone is working off their own cvs repository which expands the same tags - which would cause the conflicts today anyway. other than that, just rebasing across a HEAD that no longer has the keywords should be a very straightforward operation. Given that we generally *backpatch* fixes (rather than make them on backbranches and merge back into head), it shouldn't affect that at all. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- 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: Magnus Hagander on 7 Jul 2010 14:39 On Wed, Jul 7, 2010 at 16:40, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Dave Page <dpage(a)pgadmin.org> writes: >> 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. > >> +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. Uh, wouldn't that simply be dealt with by replacing them with an empty line instead of removing it? > 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. Yeah, clearly I didn't say that :-) My intention was for them to be removed from head and all active back-branches at the time (e.g. we don't bother with 6.x, just the platforms that are currently being used). -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- 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: Markus Wanner on 15 Jul 2010 02:58 Hi, On 07/07/2010 08:31 PM, Andrew Dunstan wrote: > Personally I favor leaving the expanded keywords in what we import, so > that there's an exact mapping between what's in the final CVS repo and > what's in the inital git repo, and then removing them entirely. I don't > see that having old keyword expansions in the historical changesets is a > bid deal. Nobody is going to base patches on them (I hope). Sorry for being somewhat late on this discussion. Another reason keeping the expanded keywords in historic revisions that hasn't been raised so far is, that they can easily be un-expanded with a script. But it's a lot harder to do the expansion, once you are on git, if you once happen to need that info. Of course, I'd also remove the keywords from every (active?) branch as a first commit after the import. I'd even favor removing those lines completely, just as sort of a cleanup commit. And no, that shouldn't pose any problem with outstanding patches, except you are fiddling with the tag itself. In which case you deserve to get a conflict. ;-) Regards Markus Wanner -- 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: Marko Kreen on 15 Jul 2010 13:15 On 7/7/10, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > 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. AFAIK that's what CVS actually keeps in repo, it expands keywords when writing files out. > 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. I would prefer that the diffs should match what CVS gives / what got committed. Sanity-checking by comparing CVS checkout with GIT checkout with unexpanded keywords can be scripted easily enough, and is one-time affair. But humans want to review old diffs quite more frequently... +1 keeping keywords, but unexpanded. -- marko -- 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 15 Jul 2010 13:26 Marko Kreen wrote: > On 7/7/10, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > >> 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. >> > > AFAIK that's what CVS actually keeps in repo, it expands keywords > when writing files out. > > No. It stores the expanded keyword. Just look in the ,v files in a CVS mirror and you'll see them. 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
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 Prev: [HACKERS] cvs to git migration - keywords Next: Python Interface Hacking |