Re: cvs to git migration - keywords

Поиск
Список
Период
Сортировка
От Marko Kreen
Тема Re: cvs to git migration - keywords
Дата
Msg-id AANLkTinvUKNYn6Ujep7X5uac6CtDRmK8P4GxbOE1gaOh@mail.gmail.com
обсуждение исходный текст
Ответ на Re: cvs to git migration - keywords  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: cvs to git migration - keywords  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
On 7/7/10, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Per-column collation, proof of concept
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: SHOW TABLES