On 6/2/09, Markus Wanner <markus@bluegap.ch> wrote:
> Quoting "Marko Kreen" <markokr@gmail.com>:
> > > I don't care half as much about the keyword expansion stuff - that's
> > > doomed to disappear anyway.
> > >
> >
> > But this is one aspect we need to get right for the conversion.
> >
>
> What's your definition of "right"? I personally prefer the keyword
> expansion to match a cvs checkout as closely as possible.
This is Definitely Wrong (tm). You seem to be thinking that comparing
GIT checkout to random parallel CVS checkout (eg. from .tgz.) is the
main use-case. It is not. Browsing history and looking and diffs
between versions is. And expanded CVS keywords would be total PITA
for that.
> > So preferably we test it sooner not later.
> >
>
> I actually *am* testing against that. As mentioned, the only differences
> are insignificant, IMO. For example having "1.1.1.1" instead of "1.1" (or
> vice versa, I don't remember).
Why have those at all...
> > I think Aidan got it right - expand $PostgreSQL$ and others that are
> > actually expanded on current repo, but not $OpenBSD$ and others
> > coming from external sources.
> >
>
> AFAIU Aidan proposed the exact opposite.
Ah, sorry, my thinko. s/expanded/stripped/. Take Aidan's description
as authoritative.. :)
> I'm proposing to leave both expanded, as in a CVS checkout and as shipped
> in the source release tarballs.
No, the noise they add to history would seriously hurt usability.
> > I'd prefer we immediately test full conversion and not leave some
> > steps to last moment.
> >
>
> IMO that would equal to changing history, so that a checkout from git
> doesn't match a released tarball as good as possible.
We need to compare against tarballs only when checking the conversion.
And only then. Writing few scripts for that should not be a problem.
> What you call "leave(ing) some steps to last moment" is IMO not part of the
> conversion. It's rather a conscious decision to drop these keywords as soon
> as we switch to git. This step should be represented in history as a
> separate commit, IMO.
The question is how they should appear in historical commits.
I have no strong opinion whether to edit them out or not in the future.
Doing it during the periodic reindent would be good moment tho'.
--
marko