Re: Some git conversion issues

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Magnus Hagander" <magnus(at)hagander(dot)net>
Cc: "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Some git conversion issues
Date: 2010-07-20 14:04:26
Message-ID: 4C45669A0200002500033961@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Magnus Hagander <magnus(at)hagander(dot)net> wrote:

>> I believe revision 1.1.1.1 is normally seen only for file brought
>> in through the "cvs import" command. "vendor branch" would make
>> some sense as a commit message for an import.
>
> Yeah, something like that. But why do we for the file above have
> one "initial revision" and one "vendor branch", whereas for other
> files we don't? (and there's no difference between them)

Hmmm... I quick check of CVS documentation indicates that 1.1.1 is
reserved for the "vendor branch" created by an import. New vendor
versions can be imported and will bump 1.1.1.1 to 1.1.1.2 and so on.
When you commit a modification to a vendor branch file, it goes
onto the trunk. So, either there was something which *looked* like
a modification to CVS which got massaged out (whitespace or some
such), or someone independently imported the file and someone
(possibly a different someone) committed the file independently of
the import. I think the latter is probably more likely, but the
former seems within the realm of possibility.

Where they are identical, unless the imported version is included in
any tag or PostgreSQL branch, I would eliminate it and keep the
"normal" copy. Short of maintaining a coherent history, I don't see
the point of keeping two separate but identical revisions of a file.

-Kevin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-07-20 14:05:04 Re: Explicit psqlrc
Previous Message David Christensen 2010-07-20 14:00:36 Re: Explicit psqlrc