From: Robert Haas on
On Wed, Jul 7, 2010 at 10:57 AM, 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.

I'm sure it did...

--
Robert Haas
EnterpriseDB: 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
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.

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.

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: Robert Haas on
On Wed, Jul 7, 2010 at 5:01 AM, Magnus Hagander <magnus(a)hagander.net> 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.
>
> 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.
>
> It really comes down to which is most important - being able to get
> "easy to use diffs" between old revisions, or keeping history intact.
>
> Obviously, for all *new* commits, either one of these two methods will
> make the diffs readable. And if they are new commits, well, they are
> by definition not history that needs to be kept :-)
>
> Thoughts?

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.

Maybe I'm smoking crack, though...

--
Robert Haas
EnterpriseDB: 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: Aidan Van Dyk on
* Dave Page <dpage(a)pgadmin.org> [100707 05:05]:
>
> +1 for #1. Changing history and the resulting possibility of becoming
> one's own grandfather always makes me nervous.

But, since we're already using CVS, our grandfather is already our
granddaughter...

I'll just point out that if you "expand" the CVS keywords in the
conversion, then your git will differe from every CVS branch/date/tag
checkout I do...

Remember... Keywords don't *need* to be expanded...

And yes, Magnus, I found that old cvs->pg stuff, I'm trying to get that
info to you today...

a.
--
Aidan Van Dyk Create like a god,
aidan(a)highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
From: Andrew Dunstan on


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).

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