Re: Hacking on PostgreSQL via GIT

Hi Florian,

I am right now running an rsync of the Pg CVS repo to my work machine to
get a git import underway. I'm rather keen on seeing your cool PITR Pg
project go well and I have some git+cvs fu I can apply here (being one
of the git-cvsimport maintainers) ;-)

For the kind of work you'll be doing (writing patches that you'll want
to be rebasing onto the latest HEAD for merging later) git is probably
the best tool. That's what I use it for... tracking my experimental /
custom branches of projects that use CVS or SVN :-)

Initially, I'll post it on http://git.catalyst.net.nz/ and I can run a
daily import for you - once that's in place you can probably get a repo
with your work on http://repo.or.cz/

cheers,

martin
--
-----------------------------------------------------------------------
Martin @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
OFFICE: +64(4)916-7224 UK: 0845 868 5733 ext 7224 MOB: +64(21)364-017
Make things as simple as possible, but no simpler - Einstein
-----------------------------------------------------------------------

Martin Langhoff wrote:

> Hi Florian,
>
> I am right now running an rsync of the Pg CVS repo to my work machine to
> get a git import underway. I'm rather keen on seeing your cool PITR Pg
> project go well and I have some git+cvs fu I can apply here (being one
> of the git-cvsimport maintainers) ;-)
>
> For the kind of work you'll be doing (writing patches that you'll want
> to be rebasing onto the latest HEAD for merging later) git is probably
> the best tool. That's what I use it for... tracking my experimental /
> custom branches of projects that use CVS or SVN :-)
>
> Initially, I'll post it on http://git.catalyst.net.nz/ and I can run a
> daily import for you - once that's in place you can probably get a repo
> with your work on http://repo.or.cz/

Well, now that more than one of us are working with git on PostgreSQL...

I've had a repo conversion running for a while... I've only got it to what
I consider "stable" last week:
http://repo.or.cz/w/PostgreSQL.git
git://repo.or.cz/PostgreSQL.git

Note that this is a "special" conversion - I intentionally "unmunge" all the
$PostgreSQL$ tags in this repo.

I hate the Keyword expansion, and it only servers to make otherwise
automatically merging a manual process. So I specifically go through and
un-munge any keyword a-like things before stomping it into GIT.

For those interested int he conversion process, I've used a slightly
modified version of fromcvs (A ruby cvs to git/Hg tool), and it runs on all
of pgsql in about 20 minutes.

I gave up on git-svn (because of both speed and my in-ablility to
easy "filter" out Keywords, etc) and git-cvsimport (because cvsps doesn't
seem to like pgsql's repo)

I "update" the git repo daily, based on an anonymous rsync of the cvsroot.
If the anon-rsync is updated much more frequently, and people think my git
conversion should match it, I have no problem having cron run it more than
daily.

Also - note that I give *no* guarentees of it's integrity, etc.

I've "diffed" a CVS checkout and a git checkout, and the are *almost*
identical. Almost, because it seems like my git repository currently has 3
files that a cvs checkout doesn't:
backend/parser/gram.c |12088 +++++++++++++++++++++++++++
interfaces/ecpg/preproc/pgc.c | 2887 ++++++
interfaces/ecpg/preproc/preproc.c |16988 ++++++++++++++++++++++++++++++++++

And at this point, I haven't been bothered to see where those files came
from (and where they dissapear) in CVS and why my import isn't picking that
up... I could probably be pushed if others find this repo really useful,
but those files problematic...

* Aidan Van Dyk <aidan(at)highrise(dot)ca> [070416 14:08]:

> Note that this is a "special" conversion - I intentionally "unmunge" all the
> $PostgreSQL$ tags in this repo.

Blah - and I just noticed that I actually "missed" the $PostgreSQL$
(although I did catch the Date/Modified/From/etc)...

> I hate the Keyword expansion, and it only servers to make otherwise
> automatically merging a manual process. So I specifically go through and
> un-munge any keyword a-like things before stomping it into GIT.

Expect it to change in the next little while once more ;-)

a.

--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.

Martin Langhoff wrote:
> Hi Florian,
>
> I am right now running an rsync of the Pg CVS repo to my work machine to
> get a git import underway. I'm rather keen on seeing your cool PITR Pg
> project go well and I have some git+cvs fu I can apply here (being one
> of the git-cvsimport maintainers) ;-)
Cool - I'm new to git, so I really appreciate any help that I can get.

> For the kind of work you'll be doing (writing patches that you'll want
> to be rebasing onto the latest HEAD for merging later) git is probably
> the best tool. That's what I use it for... tracking my experimental /
> custom branches of projects that use CVS or SVN :-)
Thats how I figured I'd work - though I don't yet understand what
the advantage of "rebase" is over "merge".

Currently, I've setup a git repo that pulls in the changes from the SVN
repo, and pushed them to my main soc git repo. On that main repo I have
two branches, master and pgsql-head, and I call "cg-merge pgsql-head"
if I want to merge with CVS HEAD.

> Initially, I'll post it on http://git.catalyst.net.nz/ and I can run a
> daily import for you - once that's in place you can probably get a repo
> with your work on http://repo.or.cz/
Having a git mirror of the pgsql CVS would be great.
BTW, I've just check out repo.or.cz, and noticed that there is already a
git mirror of the pgsql CVS: http://repo.or.cz/w/PostgreSQL.git

greetings + thanks
Florian Pflug

Aidan Van Dyk wrote:
> Martin Langhoff wrote:
> Well, now that more than one of us are working with git on PostgreSQL...
>
> I've had a repo conversion running for a while... I've only got it to what
> I consider "stable" last week:
> http://repo.or.cz/w/PostgreSQL.git
> git://repo.or.cz/PostgreSQL.git
Ah - thats what I just stumbled over ;-)

> For those interested int he conversion process, I've used a slightly
> modified version of fromcvs (A ruby cvs to git/Hg tool), and it runs on all
> of pgsql in about 20 minutes.
>
> I gave up on git-svn (because of both speed and my in-ablility to
> easy "filter" out Keywords, etc) and git-cvsimport (because cvsps doesn't
> seem to like pgsql's repo)
Yeah, git-cvsimport didn't work for me either...

> I "update" the git repo daily, based on an anonymous rsync of the cvsroot.
> If the anon-rsync is updated much more frequently, and people think my git
> conversion should match it, I have no problem having cron run it more than
> daily.
>
> Also - note that I give *no* guarentees of it's integrity, etc.
>
> I've "diffed" a CVS checkout and a git checkout, and the are *almost*
> identical. Almost, because it seems like my git repository currently has 3
> files that a cvs checkout doesn't:
> backend/parser/gram.c |12088 +++++++++++++++++++++++++++
> interfaces/ecpg/preproc/pgc.c | 2887 ++++++
> interfaces/ecpg/preproc/preproc.c |16988 ++++++++++++++++++++++++++++++++++
>
> And at this point, I haven't been bothered to see where those files came
> from (and where they dissapear) in CVS and why my import isn't picking that
> up... I could probably be pushed if others find this repo really useful,
> but those files problematic...
Thats interesting - the SVN mirror of the pgsql CVS at
http://projects.commandprompt.com/public/pgsql/browser
has exactly the same problem with those 3 files, as I found out the hard way ;-)

In the case of pgc.c, I've compared that revisions in CVS with the one in
SVN. SVN include the cvs-version 1.5 if this file in trunk, which seems to
be the last version of that file in CVS HEAD. Interestingly,
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/preproc/Attic/pgc.c
shows no trace of the file being deleted from HEAD either - it just shows
that it was removed from WIN32_DEV. But still a CVS checkout doesn't include
that file...

Since 3 tools (cvsweb, git-cvsimport and whatever commandprompt uses to create
the SVN mirror) all come to the same conclusion regarding this file, I think
that this is caused by some corruption of the CVS repository - but I don't have
the cvs-fu to debug this...

greetings, Florian Pflug

Aidan Van Dyk wrote:

> I've "diffed" a CVS checkout and a git checkout, and the are *almost*
> identical. Almost, because it seems like my git repository currently has 3
> files that a cvs checkout doesn't:
> backend/parser/gram.c |12088 +++++++++++++++++++++++++++
> interfaces/ecpg/preproc/pgc.c | 2887 ++++++
> interfaces/ecpg/preproc/preproc.c |16988 ++++++++++++++++++++++++++++++++++
>
> And at this point, I haven't been bothered to see where those files came
> from (and where they dissapear) in CVS and why my import isn't picking that
> up... I could probably be pushed if others find this repo really useful,
> but those files problematic...

These files are generated (from gram.y, pgc.l and preproc.y
respectievly) and are not present in the CVS repo, though I think they
have been at some point.

It's strange that other generated files (that have also been in the repo
in the past) like preproc.h are not showing up.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> These files are generated (from gram.y, pgc.l and preproc.y
> respectievly) and are not present in the CVS repo, though I think they
> have been at some point.

> It's strange that other generated files (that have also been in the repo
> in the past) like preproc.h are not showing up.

The weird thing about these files is that the CVS history shows commits
on HEAD later than the file removal commit. I don't recall if Vadim
unintentionally re-added the files before making those commits ... but
if he did, you'd think it'd have taken another explicit removal to get
rid of them in HEAD. More likely, there was some problem in his local
tree that allowed a "cvs commit" to think it should update the
repository with copies of the derived files he happened to have.

I think this is a corner case that CVS handles in a particular way and
the tools people are using to read the repository handle in a different
way. Which would be a bug in those tools, since CVS's interpretation
must be right by definition.

regards, tom lane

Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>> These files are generated (from gram.y, pgc.l and preproc.y
>> respectievly) and are not present in the CVS repo, though I think they
>> have been at some point.
>
>> It's strange that other generated files (that have also been in the repo
>> in the past) like preproc.h are not showing up.
>
> The weird thing about these files is that the CVS history shows commits
> on HEAD later than the file removal commit. I don't recall if Vadim
> unintentionally re-added the files before making those commits ... but
> if he did, you'd think it'd have taken another explicit removal to get
> rid of them in HEAD. More likely, there was some problem in his local
> tree that allowed a "cvs commit" to think it should update the
> repository with copies of the derived files he happened to have.
>
> I think this is a corner case that CVS handles in a particular way and
> the tools people are using to read the repository handle in a different
> way. Which would be a bug in those tools, since CVS's interpretation
> must be right by definition.

The question is if it'd be acceptable to manually remove that last commit
from the repository. I guess simply readding, and then removing the files
again should do the trick, though I'd be cleaner to fix remove the
offending commit in the first place. Should postgres ever decide to switch
to another version control system (which I don't advocate), that'd be
one obstacle less to deal with...

Or is the risk of causing breakage too high?

greetings, Florian Pflug

aidan(at)highrise(dot)ca (Aidan Van Dyk) writes:
> I've "diffed" a CVS checkout and a git checkout, and the are *almost*
> identical. Almost, because it seems like my git repository currently has 3
> files that a cvs checkout doesn't:
> backend/parser/gram.c |12088 +++++++++++++++++++++++++++
> interfaces/ecpg/preproc/pgc.c | 2887 ++++++
> interfaces/ecpg/preproc/preproc.c |16988 ++++++++++++++++++++++++++++++++++
>
> And at this point, I haven't been bothered to see where those files came
> from (and where they dissapear) in CVS and why my import isn't picking that
> up... I could probably be pushed if others find this repo really useful,
> but those files problematic...

Those three files are normally generated by either flex or bison
(gram.c depends on gram.y, pgc.c on pgc.l, and preproc.c on
preproc.y); I'd suggest removing those three files from your git
repository.
--
"cbbrowne","@","acm.org"
http://cbbrowne.com/info/rdbms.html
"They laughed at Columbus, they laughed at Fulton, they laughed at the
Wright brothers. But they also laughed at Bozo the Clown."
-- Carl Sagan

fgp(at)phlo(dot)org ("Florian G. Pflug") writes:
> Martin Langhoff wrote:
>> Hi Florian,
>> I am right now running an rsync of the Pg CVS repo to my work
>> machine to
>> get a git import underway. I'm rather keen on seeing your cool PITR Pg
>> project go well and I have some git+cvs fu I can apply here (being one
>> of the git-cvsimport maintainers) ;-)
> Cool - I'm new to git, so I really appreciate any help that I can get.
>
>> For the kind of work you'll be doing (writing patches that you'll want
>> to be rebasing onto the latest HEAD for merging later) git is probably
>> the best tool. That's what I use it for... tracking my experimental /
>> custom branches of projects that use CVS or SVN :-)
> Thats how I figured I'd work - though I don't yet understand what
> the advantage of "rebase" is over "merge".
>
> Currently, I've setup a git repo that pulls in the changes from the SVN
> repo, and pushed them to my main soc git repo. On that main repo I have
> two branches, master and pgsql-head, and I call "cg-merge pgsql-head"
> if I want to merge with CVS HEAD.
>
>> Initially, I'll post it on http://git.catalyst.net.nz/ and I can run a
>> daily import for you - once that's in place you can probably get a repo
>> with your work on http://repo.or.cz/
> Having a git mirror of the pgsql CVS would be great.
> BTW, I've just check out repo.or.cz, and noticed that there is already a
> git mirror of the pgsql CVS: http://repo.or.cz/w/PostgreSQL.git

This strikes me as being a really super thing, having both Subversion
and Git repositories publicly available that are tracking the
PostgreSQL sources.

Stepping back to the SCM discussion, people were interested in finding
out what merits there were in having these sorts of SCMs, and in
finding out what glitches people might discover (e.g. - like the files
where the CVS repository is a bit schizophrenic as to whether they are
still there or not...). Having these repositories should allow some
of this experimentation to take place now.

I'd be interested in fiddling with a Git repository, at some point;
I'll happily wait a bit to start drawing from one of these existing
ones, to let the dust settle and to let things stabilize a bit.
--
(reverse (concatenate 'string "moc.enworbbc" "@" "enworbbc"))
http://linuxdatabases.info/info/emacs.html
"Support your local medical examiner - die strangely."
-- Blake Bowers

* Florian G. Pflug <fgp(at)phlo(dot)org> [070416 16:16]:

> >I think this is a corner case that CVS handles in a particular way and
> >the tools people are using to read the repository handle in a different
> >way. Which would be a bug in those tools, since CVS's interpretation
> >must be right by definition.

;-)

Would anyone know if these were "hand moved" to Attic? For instance, I
*can't* seem to get non-dead files into Attic, no matter what I try with
my cvs (on debian). But I haven't gone through the last 8 years of
CVS's CVS logs to see if they fixed a bug in the cvs server code that
would allow a non-dead HEAD rcs to be in the Attic...

> The question is if it'd be acceptable to manually remove that last commit
> from the repository. I guess simply readding, and then removing the files
> again should do the trick, though I'd be cleaner to fix remove the
> offending commit in the first place. Should postgres ever decide to switch
> to another version control system (which I don't advocate), that'd be
> one obstacle less to deal with...
>
> Or is the risk of causing breakage too high?

Well, I've "hand fixed" this in my conversion process so my git
conversion should not have this problem...

I'm not a fan of mucking around by hand in CVS. It's only because of
the short comings of CVS that it's necessary to every resort to that.
So I don't think re-adding/deleting it is worth it...

I've updated the repo.or.cz/PostgreSQL.git again - and this time it
should be pretty good. Consider it "usable" to clone off and follow CVS
development with... I won't re-convert the whole thing again, and will
just provide daily updates to it now. Unless anybody finds issues with
it...

Ignore the "public" branch in there - that got in in an errant push, and
I don't know how to remove branches on repo.or.cz. I'm now just putting
"conversion notes" up in the public branch... IT's *not* a PostgreSQL
branch.

a.

--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.

Aidan Van Dyk <aidan(at)highrise(dot)ca> writes:
> Would anyone know if these were "hand moved" to Attic?

Seems unlikely, since there's a commit log entry for the removal. But
this all happened seven-plus years ago and I'm sure there's an old CVS
bug involved *somewhere*.

I like the idea of re-adding and then re-removing the files on HEAD.
Does anyone think that poses any real risk?

regards, tom lane

* Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [070416 19:03]:
> Aidan Van Dyk <aidan(at)highrise(dot)ca> writes:
> > Would anyone know if these were "hand moved" to Attic?
>
> Seems unlikely, since there's a commit log entry for the removal. But
> this all happened seven-plus years ago and I'm sure there's an old CVS
> bug involved *somewhere*.
>
> I like the idea of re-adding and then re-removing the files on HEAD.
> Does anyone think that poses any real risk?

No - it even fixed the "hand moved" test I had done trying to create an
Attic with, when trying to figure out how they got that way in the first
place...

What I did when I converted the repo was just hand edit those files to
have a state of "dead" to match their position in Attic for those RCS
revs. If you "add" them and remove them, I believe my GIT conversion
will actually "follow" that correctly... If not - I just rm -Rf it and
let it go from scratch "one more time"... I'm glad computers are good
at that type of repetitive task...

a.

--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.

Aidan Van Dyk <aidan(at)highrise(dot)ca> writes:
> * Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [070416 19:03]:
>> I like the idea of re-adding and then re-removing the files on HEAD.
>> Does anyone think that poses any real risk?

> No - it even fixed the "hand moved" test I had done trying to create an
> Attic with, when trying to figure out how they got that way in the first
> place...

Well, it doesn't work :-(. CVS is definitely a bit confused about the
status of these files:

$ touch gram.c
$ cvs add gram.c
cvs add: gram.c added independently by second party
$ cvs remove gram.c
cvs remove: file `gram.c' still in working directory
cvs remove: 1 file exists; remove it first
$ rm gram.c
rm: remove regular empty file `gram.c'? y
$ cvs remove gram.c
cvs remove: nothing known about `gram.c'

So there's no way, apparently, to fix the state of these files through
the "front door". Shall we try the proposed idea of hand-moving the
files out of the Attic subdirectory, whereupon they should appear live
and we can cvs remove them again? I have login on cvs.postgresql.org
and can try this, but I'd like confirmation from someone that this is
unlikely to break things. Is there any hidden state to be fixed in the
CVS repository? I don't see any ...

regards, tom lane

I wrote:
> So there's no way, apparently, to fix the state of these files through
> the "front door".

I take that back: the right sequence involving a "cvs update" got me
into a state where it thought the files were "locally modified", and
then I could commit and "cvs remove" and commit again. So hopefully
it's all cleaned up now --- at least the states of the files look
reasonable in cvsweb.

regards, tom lane

Tom Lane wrote:
> Aidan Van Dyk <aidan(at)highrise(dot)ca> writes:
>
>> * Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [070416 19:03]:
>>
>>> I like the idea of re-adding and then re-removing the files on HEAD.
>>> Does anyone think that poses any real risk?
>>>
>
>
>> No - it even fixed the "hand moved" test I had done trying to create an
>> Attic with, when trying to figure out how they got that way in the first
>> place...
>>
>
> Well, it doesn't work :-(. CVS is definitely a bit confused about the
> status of these files:
>
> $ touch gram.c
> $ cvs add gram.c
> cvs add: gram.c added independently by second party
> $ cvs remove gram.c
> cvs remove: file `gram.c' still in working directory
> cvs remove: 1 file exists; remove it first
> $ rm gram.c
> rm: remove regular empty file `gram.c'? y
> $ cvs remove gram.c
> cvs remove: nothing known about `gram.c'
>
> So there's no way, apparently, to fix the state of these files through
> the "front door". Shall we try the proposed idea of hand-moving the
> files out of the Attic subdirectory, whereupon they should appear live
> and we can cvs remove them again? I have login on cvs.postgresql.org
> and can try this, but I'd like confirmation from someone that this is
> unlikely to break things. Is there any hidden state to be fixed in the
> CVS repository? I don't see any ...
>
>

Forgive my caution, but I'd suggest trying on a copy first.

cheers

andrew

Andrew Dunstan wrote:
> Tom Lane wrote:

> >So there's no way, apparently, to fix the state of these files through
> >the "front door". Shall we try the proposed idea of hand-moving the
> >files out of the Attic subdirectory, whereupon they should appear live
> >and we can cvs remove them again? I have login on cvs.postgresql.org
> >and can try this, but I'd like confirmation from someone that this is
> >unlikely to break things. Is there any hidden state to be fixed in the
> >CVS repository? I don't see any ...
>
> Forgive my caution, but I'd suggest trying on a copy first.

Too late ;-)

FWIW my CVSup copy seems happy with the change; it reported this when I
updated it:

$ pgcvsup
Connected to cvsup.postgresql.org
Updating collection repository/cvs
Edit pgsql/src/backend/parser/gram.c,v -> Attic
Edit pgsql/src/backend/utils/mb/encnames.c,v
Edit pgsql/src/bin/pg_dump/pg_dump.c,v
Edit pgsql/src/bin/psql/common.c,v
Edit pgsql/src/include/pg_config.h.win32,v
Edit pgsql/src/interfaces/ecpg/preproc/pgc.c,v -> Attic
Edit pgsql/src/interfaces/ecpg/preproc/preproc.c,v -> Attic
Edit pgsql/src/tools/msvc/Solution.pm,v
Rsync sup/repository/checkouts.cvs
Finished successfully

The gram.c,v file looks good -- it has the expected "state dead;" line.
A checked out tree from that updates fine. A "cvs update" to a checked
out tree direct from the main CVS server also updates fine.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Florian G. Pflug wrote:
>> Initially, I'll post it on http://git.catalyst.net.nz/ and I can run a
>> daily import for you - once that's in place you can probably get a repo
>> with your work on http://repo.or.cz/

Ok - you can now clone from http://git.catalyst.net.nz/postgresql.git
viewable from http://git.catalyst.net.nz/gitweb too. It's 24hs behind,
and I'm sorting the updating scripts that will run daily.

The HEAD of CVS is renamed to cvshead there. All the other branches and
tags are untouched. Please DO check that the tip of cvshead matches a
CVS checkout with -kk. I've had limited time to sanitycheck the import ;-)

cheers,

m
--
-----------------------------------------------------------------------
Martin @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
OFFICE: +64(4)916-7224 UK: 0845 868 5733 ext 7224 MOB: +64(21)364-017
Make things as simple as possible, but no simpler - Einstein
-----------------------------------------------------------------------

* Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [070416 21:11]:
> I wrote:
> > So there's no way, apparently, to fix the state of these files through
> > the "front door".
>
> I take that back: the right sequence involving a "cvs update" got me
> into a state where it thought the files were "locally modified", and
> then I could commit and "cvs remove" and commit again. So hopefully
> it's all cleaned up now --- at least the states of the files look
> reasonable in cvsweb.

And my GIT conversion handled that nicely too. Looks good (at least
from the GIT PoV).

Now, on my hand-crafted GIT repo - you see them in and out now with
Tom's commits. But any *real* conversion tracking the *actual* RCS cvs
states should have them checked out from 1999 to now in the state they
were from vadim's last changes, and Tom's first commit will "truncate"
them (because he checked them in as empty files), and the 2nd commit
will remove them again.

So it's still a "gotcha" if you're trying to get a copy of CVS from ages
ago via one of the alternative SCM conversions...

But my git one works, so I'll let others worry about the others ;-)

a.

--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.

Aidan Van Dyk <aidan(at)highrise(dot)ca> writes:
> Now, on my hand-crafted GIT repo - you see them in and out now with
> Tom's commits. But any *real* conversion tracking the *actual* RCS cvs
> states should have them checked out from 1999 to now in the state they
> were from vadim's last changes, and Tom's first commit will "truncate"
> them (because he checked them in as empty files), and the 2nd commit
> will remove them again.

> So it's still a "gotcha" if you're trying to get a copy of CVS from ages
> ago via one of the alternative SCM conversions...

It shouldn't be a big problem, assuming the checkout preserves the file
dates --- they'll look older than the source files and so a rebuild will
happen anyway in such a checkout.

regards, tom lane

Florian G. Pflug wrote:
> Cool - I'm new to git, so I really appreciate any help that I can get.

Great - I am a SoC mentor for 2 other projects (git and moodle) so I've
got some time set aside for SoC stuff. You might as well take advantage
of it :-)

>> For the kind of work you'll be doing (writing patches that you'll want
>> to be rebasing onto the latest HEAD for merging later) git is probably
>> the best tool. That's what I use it for... tracking my experimental /
>> custom branches of projects that use CVS or SVN :-)
>
> Thats how I figured I'd work - though I don't yet understand what
> the advantage of "rebase" is over "merge".

Probably during your development cycle you'll want to merge the changes
from cvshead into your dev branch - that's what you seem to be doing.
Great. Later when you are getting things ready for actual merging into
CVS you'll want to prepare a series of patches that apply to the top of
cvshead. That's where the rebase tools become useful.

> Currently, I've setup a git repo that pulls in the changes from the SVN
> repo, and pushed them to my main soc git repo. On that main repo I have
> two branches, master and pgsql-head, and I call "cg-merge pgsql-head"
> if I want to merge with CVS HEAD.

You are doing the right thing. If possible, I'd suggest that you use git
instead of cogito. Recent git is as user-friendly as cogito. The main
difference is that you'll need to learn a bit about the index, and
that'll be useful.

>> Initially, I'll post it on http://git.catalyst.net.nz/ and I can run a
>> daily import for you - once that's in place you can probably get a repo
>> with your work on http://repo.or.cz/
>
> Having a git mirror of the pgsql CVS would be great.
> BTW, I've just check out repo.or.cz, and noticed that there is already a
> git mirror of the pgsql CVS: http://repo.or.cz/w/PostgreSQL.git

Yes, I've seen it, but I don't know the guy. I can ensure you have a
CVS->GIT gateway updated daily or twice daily.

cheers,

martin
--
-----------------------------------------------------------------------
Martin @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
OFFICE: +64(4)916-7224 UK: 0845 868 5733 ext 7224 MOB: +64(21)364-017
Make things as simple as possible, but no simpler - Einstein
-----------------------------------------------------------------------

Tom Lane wrote:

> It shouldn't be a big problem, assuming the checkout preserves the file
> dates --- they'll look older than the source files and so a rebuild will
> happen anyway in such a checkout.
>

Actually this is a problem with at least SVN. A "svn export" will
create files with the original repository dates, but a "svn checkout"
will use the current time unless you enable a config option for your
local svn client.

Kris Jurka

Chris Browne wrote:
> This strikes me as being a really super thing, having both Subversion
> and Git repositories publicly available that are tracking the
> PostgreSQL sources.
>
> Stepping back to the SCM discussion, people were interested in finding
> out what merits there were in having these sorts of SCMs, and in
> finding out what glitches people might discover (e.g. - like the files
> where the CVS repository is a bit schizophrenic as to whether they are
> still there or not...). Having these repositories should allow some
> of this experimentation to take place now.

Yep. It'd be nice to have official GIT and SVN etc. mirrors of the main
CVS repository. There's no pressing reason for the PostgreSQL project to
switch from CVS, but we could provide alternatives to developers. As
long as you can create a diff to send to pgsql-patches, it doesn't
matter which version control system you use. I'm interested in trying
GIT or Monotone myself, presumably they would be good for managing
unapplied, work-in-progress patches.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

* Martin Langhoff <martin(at)catalyst(dot)net(dot)nz> [070417 17:32]:

> > Having a git mirror of the pgsql CVS would be great.
> > BTW, I've just check out repo.or.cz, and noticed that there is already a
> > git mirror of the pgsql CVS: http://repo.or.cz/w/PostgreSQL.git
>
> Yes, I've seen it, but I don't know the guy. I can ensure you have a
> CVS->GIT gateway updated daily or twice daily.

I'm an unknown here, I know - I've used PostgreSQL for years, but only
recently started following the development community... And at this
point I'm still pretty much just following, hence my interest in getting
a GIT repot of PostgreSQL. GIT is *very* helful at a "new" code-base.

I have my CVS->GIT conversion running hourly from the anon-rsync of the
cvsroot. I don't know the specifics of the PostgreSQL rsync/mirror
setup, so I may be pulling it more frequently than it's actually
published, but until I hear from someone that tells me I'm taxing to
many rsync resources, I'll just leave it that way... The CVS->GIT
conversion is cheap - it's the rsync that takes most of the time... I
can run it more frequently if people think it would be valuble and the
rsync-admins don't care...

And remember the warning I gave that my conversion is *not* a direct CVS
import - I intentionally *unexpand* all Keywords before stuffing them
into GIT so that merging and branching can ignore all the Keyword
conflicts...

a.

--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.

Aidan Van Dyk <aidan(at)highrise(dot)ca> writes:
> I have my CVS->GIT conversion running hourly from the anon-rsync of the
> cvsroot. I don't know the specifics of the PostgreSQL rsync/mirror
> setup, so I may be pulling it more frequently than it's actually
> published, but until I hear from someone that tells me I'm taxing to
> many rsync resources, I'll just leave it that way...

The anoncvs mirror updates once an hour, so you're fine.

regards, tom lane

Aidan Van Dyk wrote:
> I'm an unknown here, I know - I've used PostgreSQL for years, but only
> recently started following the development community... And at this

I'm probably unknown here as well. Hi everyone ;-)

> And remember the warning I gave that my conversion is *not* a direct CVS
> import - I intentionally *unexpand* all Keywords before stuffing them
> into GIT so that merging and branching can ignore all the Keyword
> conflicts...

My import is unexpanding those as well to support rebasing and merging
better.

So - if you are committed to providing your gateway long term to
Florian, I'm happy to drop my gateway in favour of yours.

(Florian, before basing your code on either you should get a checkout of
Aidan's and mine and check that the tips of the branches you are working
on match the cvs branches -- the cvsimport code is good but whereever
CVS is involved, there's a lot of interpretation at play, a sanity check
is always good).

cheers,

m
--
-----------------------------------------------------------------------
Martin @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
OFFICE: +64(4)916-7224 UK: 0845 868 5733 ext 7224 MOB: +64(21)364-017
Make things as simple as possible, but no simpler - Einstein
-----------------------------------------------------------------------

Martin Langhoff wrote:
> Aidan Van Dyk wrote:
>> And remember the warning I gave that my conversion is *not* a direct CVS
>> import - I intentionally *unexpand* all Keywords before stuffing them
>> into GIT so that merging and branching can ignore all the Keyword
>> conflicts...
>
> My import is unexpanding those as well to support rebasing and merging
> better.
>
> So - if you are committed to providing your gateway long term to
> Florian, I'm happy to drop my gateway in favour of yours.

There seem to be other people than me who are interested in a git
mirror. Maybe we could declare one of those mirrors the
"official" one - I guess things would be easier if all people
interested in using git would use the same mirror...

What do you guys think?

> (Florian, before basing your code on either you should get a checkout of
> Aidan's and mine and check that the tips of the branches you are working
> on match the cvs branches -- the cvsimport code is good but whereever
> CVS is involved, there's a lot of interpretation at play, a sanity check
> is always good).
I actually hoped that I could just take my current git repo, and rebase
my branch onto one of those two repos - or does rebase only work from
an ancestor to a descendant?

greetings, Florian Pflug

* Florian G. Pflug <fgp(at)phlo(dot)org> [070417 20:30]:

> >So - if you are committed to providing your gateway long term to
> >Florian, I'm happy to drop my gateway in favour of yours.
>
> There seem to be other people than me who are interested in a git
> mirror. Maybe we could declare one of those mirrors the
> "official" one - I guess things would be easier if all people
> interested in using git would use the same mirror...
>
> What do you guys think?

I'll provide that gateway as long as I have access to hardware and
access that can keep up with PostgreSQL CVS...

Of course, the beauty of a DVCS is that we don't really need an official
one... And with GIT, you can even "graft" history in if you want. So
you could even "start" your GIT work from a cvs checkout of whenever,
and "graft" any commit from any of the CVS->GIT conversion history as a
parent to your starting point.

a.

--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.

Martin Langhoff <martin(at)catalyst(dot)net(dot)nz> writes:
> Aidan Van Dyk wrote:
>> And remember the warning I gave that my conversion is *not* a direct CVS
>> import - I intentionally *unexpand* all Keywords before stuffing them
>> into GIT so that merging and branching can ignore all the Keyword
>> conflicts...

> My import is unexpanding those as well to support rebasing and merging
> better.

Um ... why do either of you feel there's an issue there?

We switched over to $PostgreSQL$ a few years ago specifically to avoid
creating merge problems for downstream repositories. If there are any
other keyword expansions left in the source text I'd vote to remove
them. If you have a problem with $PostgreSQL$, why?

regards, tom lane

Tom Lane wrote:
> Um ... why do either of you feel there's an issue there?
>
> We switched over to $PostgreSQL$ a few years ago specifically to avoid
> creating merge problems for downstream repositories. If there are any
> other keyword expansions left in the source text I'd vote to remove
> them. If you have a problem with $PostgreSQL$, why?

I have to accept the blame for not researching about the repo in the
first place. I didn't know about $PostgreSQL$ - from the looks of it, it
acts _just_ like $Id$. So I guess you use PostgreSQL instead of Id.

As GIT won't touch them, Florian will probably be just fine with his
patches, and I doubt they'll be more than a minor annoyance, if at all.

Keyword expansions are generally bad because SCM tools should track
_content_ - and keyword expansions _modify_ it to add metadata that is
somewhat redundant, obtainable in other ways, and should just not be in
the middle of the _data_. Those modifications lead to patches that have
bogus hunks and sometimes don't apply, MD5/SHA1 checksums that don't
match and a whole lot of uncertainty.

You can't just say "the content is the same" by comparing bytes or SHA1
digests if the committer, the path or the history are different. And it
is a mighty important ability for an SCM.

The argument runs much longer than that - and the flamewars are quite
entertaining. If anyone's keen we're having one right now on
git(at)vger(dot)kernel(dot)org . I am sure Pg hackers will find parallels between
keyword expansion (as a misfeature everyone is used to) and the SQL
travesties that early MySQL is famous for.

I've picked my poison... ran away from MySQL to Pg, and from CVS
/SVN/Arch to GIT. Not looking back :-)

cheers

m
--
-----------------------------------------------------------------------
Martin @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
OFFICE: +64(4)916-7224 UK: 0845 868 5733 ext 7224 MOB: +64(21)364-017
Make things as simple as possible, but no simpler - Einstein
-----------------------------------------------------------------------

* Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [070418 01:33]:

> Um ... why do either of you feel there's an issue there?
>
> We switched over to $PostgreSQL$ a few years ago specifically to avoid
> creating merge problems for downstream repositories. If there are any
> other keyword expansions left in the source text I'd vote to remove
> them. If you have a problem with $PostgreSQL$, why?

Mine is only a generic warning. I convert many CVS repos to GIT, all
using the same gateway setup, so I haven't done anything "specific" for
PostgreSQL. Most other projects are not as diciplined as PostgreSQL,
and I regularly see Modified, Date, Id, Log, etc keywords, as well as
project specific ones like PostgreSQL, OpenBSD, FreeBSD, etc...

Un-expansion *may* not be perfect...

a.

--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.

Tom Lane wrote:
> Martin Langhoff <martin(at)catalyst(dot)net(dot)nz> writes:
> > Aidan Van Dyk wrote:
> >> And remember the warning I gave that my conversion is *not* a direct CVS
> >> import - I intentionally *unexpand* all Keywords before stuffing them
> >> into GIT so that merging and branching can ignore all the Keyword
> >> conflicts...
>
> > My import is unexpanding those as well to support rebasing and merging
> > better.
>
> Um ... why do either of you feel there's an issue there?
>
> We switched over to $PostgreSQL$ a few years ago specifically to avoid
> creating merge problems for downstream repositories. If there are any
> other keyword expansions left in the source text I'd vote to remove
> them. If you have a problem with $PostgreSQL$, why?

One weird thing I noticed some time ago is that we have an $Id$ (or was
it $Header$? I don't remember) somewhere, which was supposed to be from
the upstream repo where we got the file from, but it was being expanded
to our local version to the file. We _also_ have the $PostgreSQL$ tag
in there which carries the same info.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On Wed, Apr 18, 2007 at 06:39:34PM +1200, Martin Langhoff wrote:
> Keyword expansions are generally bad because SCM tools should track
> _content_ - and keyword expansions _modify_ it to add metadata that is
> somewhat redundant, obtainable in other ways, and should just not be in
> the middle of the _data_. Those modifications lead to patches that have
> bogus hunks and sometimes don't apply, MD5/SHA1 checksums that don't
> match and a whole lot of uncertainty.

Then how do you tell what version a file is if it's outside of a
checkout?
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

* Jim C. Nasby <jim(at)nasby(dot)net> [070418 14:39]:
> On Wed, Apr 18, 2007 at 06:39:34PM +1200, Martin Langhoff wrote:
> > Keyword expansions are generally bad because SCM tools should track
> > _content_ - and keyword expansions _modify_ it to add metadata that is
> > somewhat redundant, obtainable in other ways, and should just not be in
> > the middle of the _data_. Those modifications lead to patches that have
> > bogus hunks and sometimes don't apply, MD5/SHA1 checksums that don't
> > match and a whole lot of uncertainty.
>
> Then how do you tell what version a file is if it's outside of a
> checkout?

That's what all the fun is about ;-) Some would say that "labelling" the
file is the job of the release processes. Others say it's the job of
the SCM system...

Of course I just sit on the fence because in the work I have to do, I'm
quite happy that nothing is "outside of a checkout". GIT is good enough
that I have it everywhere. I realise not everyone's that lucky..

;-)

a.

--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.

* Aidan Van Dyk <aidan(at)highrise(dot)ca> [070418 15:03]:

> > Then how do you tell what version a file is if it's outside of a
> > checkout?
>
> That's what all the fun is about ;-) Some would say that "labelling" the
> file is the job of the release processes. Others say it's the job of
> the SCM system...

Noting that if you take something "outside of a checkout" means you've
"released" it from the VCS...

--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.

Aidan Van Dyk wrote:
> * Aidan Van Dyk <aidan(at)highrise(dot)ca> [070418 15:03]:
>
> > > Then how do you tell what version a file is if it's outside of a
> > > checkout?
> >
> > That's what all the fun is about ;-) Some would say that "labelling" the
> > file is the job of the release processes. Others say it's the job of
> > the SCM system...
>
> Noting that if you take something "outside of a checkout" means you've
> "released" it from the VCS...

Which is not always what happens in reality. Consider for example that
we borrowed some files from NetBSD, OpenBSD, Tcl, zic and others. It
would be nice to know exactly at what point we borrowed the file, so we
can go to the upstream repo and check if there's any bug fix that we
should also apply to our local copy. And we _also_ modify locally the
file of course, so just digesting the file we have to get a SHA1 (or
whatever) identifier is not an option.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Jim C. Nasby wrote:
> Then how do you tell what version a file is if it's outside of a
> checkout?

It's trivial for git to answer that - the file will either be pristine,
and then we can just scan for the matching SHA1, or modified, and we can
scan (taking a weee bit more time) which are the "closest matches" in
your history, in what branches and commits.

The actual scripting for this isn't written just yet -- Linus posted a
proof-of-concept shell implementation along the lines of

git rev-list --no-merges --full-history v0.5..v0.7 --
src/widget/widget.c > rev-list

best_commit=none
best=1000000
while read commit
do
git cat-file blob "$commit:src/widget/widget.c" > tmpfile
lines=$(diff reference-file tmpfile | wc -l)
if [ "$lines" -lt "$best" ]
then
echo Best so far: $commit $lines
best=$lines
fi
done < rev-list

and it's fast. One of the good properties of this is that you can ask
for a range of your history (v0.5 to v0.7 in the example) and an exact
path (src/widget/widget.c) but you can also say --all (meaning "in all
branches") and a handwavy "over there", like src. And git will take an
extra second or two on a large repo, but tell you about all the good
candidates across the branches.

Metadata is metadata, and we can fish it out of the SCM easily - and
data is data, and it's silly to pollute it with metadata that is mostly
incidental.

If I find time today I'll post to the git list a cleaned up version of
Linus' shell script as

git-findclosestmatch <head or range or --all> path/to/scan/ \
randomfile.c

cheers,

m
--
-----------------------------------------------------------------------
Martin @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
OFFICE: +64(4)916-7224 UK: 0845 868 5733 ext 7224 MOB: +64(21)364-017
Make things as simple as possible, but no simpler - Einstein
-----------------------------------------------------------------------

On Thu, Apr 19, 2007 at 10:07:08AM +1200, Martin Langhoff wrote:
> Jim C. Nasby wrote:
> > Then how do you tell what version a file is if it's outside of a
> > checkout?
>
> It's trivial for git to answer that - the file will either be pristine,
> and then we can just scan for the matching SHA1, or modified, and we can
> scan (taking a weee bit more time) which are the "closest matches" in
> your history, in what branches and commits.
>
> The actual scripting for this isn't written just yet -- Linus posted a
> proof-of-concept shell implementation along the lines of
>
> git rev-list --no-merges --full-history v0.5..v0.7 --
> src/widget/widget.c > rev-list
>
> best_commit=none
> best=1000000
> while read commit
> do
> git cat-file blob "$commit:src/widget/widget.c" > tmpfile
> lines=$(diff reference-file tmpfile | wc -l)
> if [ "$lines" -lt "$best" ]
> then
> echo Best so far: $commit $lines
> best=$lines
> fi
> done < rev-list
>
> and it's fast. One of the good properties of this is that you can ask
> for a range of your history (v0.5 to v0.7 in the example) and an exact
> path (src/widget/widget.c) but you can also say --all (meaning "in all
> branches") and a handwavy "over there", like src. And git will take an
> extra second or two on a large repo, but tell you about all the good
> candidates across the branches.
>
> Metadata is metadata, and we can fish it out of the SCM easily - and
> data is data, and it's silly to pollute it with metadata that is mostly
> incidental.
>
> If I find time today I'll post to the git list a cleaned up version of
> Linus' shell script as
>
> git-findclosestmatch <head or range or --all> path/to/scan/ \
> randomfile.c

Not bad... took you 40 lines to answer my question. Let's see if I can
beat that...

> > Then how do you tell what version a file is if it's outside of a
> > checkout?

Answer: you look at the $Id$ (or in this case, $PostgreSQL$) tag.

Sorry, tried to get it to 2 lines, but couldn't. ;)

I understand the argument about metadata and all, and largely agree with
it. But on the other hand I think a version identifier is a critical
piece of information; it's just as critical as the file name when it
comes to identifying the information contained in the file.

Or does GIT not use filenames, either? :)
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

Jim C. Nasby wrote:
> Not bad... took you 40 lines to answer my question. Let's see if I can
> beat that...

Sure - it'll be 1 line when it's wrapped in a shell script. And then
we'll be even.

> I understand the argument about metadata and all, and largely agree with
> it. But on the other hand I think a version identifier is a critical
> piece of information; it's just as critical as the file name when it
> comes to identifying the information contained in the file.

Surely. It is important, but it's metadata and belongs elsewhere. That
metadata _is_ important doesn't mean you corrupt _data_ with it.

Just imagine that MySQL users were used to getting their SQL engine
expand $Oid$ $Tablename$ $PrimayKey$ in TEXT fields. And that when
INSERT/UPDATEing those were collapsed. And in comparisons too. Wouldn't
you say "that's metadata, can be queried in a thousand ways, does not
belong in the middle of the data"?

And the _really_ interesting version identifier is usually the "commit"
identifier, which gives you a SHA1 of the whole src directory and the
history. Projects that use git usually include that SHA1 in their build
script, so even if a user compiles off a daily snapshot or a checkout on
a random branch of your SCM, you can just ask them "what's the build
identifier?" and they'll give you a SHA1.

Actually, git can spit a nicer build identifier that includes the latest
tag, so if you see the identifier being

v8.2.<sha1>

You know it's not 8.2 "release" but a commit soon after it, identified
by that SHA1. GIT uses that during its build to insert the version
identifier, so:

$ git --version
git version 1.5.1.gf8ce

With that in your hand, you can say

# show me what commits on top of the tagged 1.5.1 have I got:
$ git log 1.5.1..gf8ce

# file src/lib/foo.c at this exact commit
git show gf8ce:src/lib/foo.c

So if you use this identifier (just call `git version`) to

- name your tarballs
- create a "build-id" file at tarball creation time
- tag your builds with a version id

And then when you have code out there in the wild, and people report
bugs or send you patches, there's a good identifier you can ask for that
covers _all_ the files.

If it happens that someone reports a bug and says they have 8.2.gg998
and you don't seem to have any gg998 commit after 8.2, you can say with
confidence: you are running some a patched Pg - please repro with a
pristine copy (or show us your code!) :-)

cheers,

m
--
-----------------------------------------------------------------------
Martin @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
OFFICE: +64(4)916-7224 UK: 0845 868 5733 ext 7224 MOB: +64(21)364-017
Make things as simple as possible, but no simpler - Einstein
-----------------------------------------------------------------------

Hi,

Alvaro Herrera wrote:
> Which is not always what happens in reality. Consider for example that
> we borrowed some files from NetBSD, OpenBSD, Tcl, zic and others. It
> would be nice to know exactly at what point we borrowed the file, so we
> can go to the upstream repo and check if there's any bug fix that we
> should also apply to our local copy. And we _also_ modify locally the
> file of course, so just digesting the file we have to get a SHA1 (or
> whatever) identifier is not an option.

I consider such information (i.e. 'where is this file coming from') to
be historical information. As such, this information clearly belongs to
the VCS sphere and should be tracked and presented by the VCS.

Advanced VCSes can import files from other projects and properly track
those files or propagate on request. Even subversion can do that to some
extent. My point here is: given a decent VCS, you don't need such
historical information as often as you do with CVS. You can sit back and
let the VCS do the job. (Like looking up, when the last 'import' of the
file from the external project happened, what changed and merge those
changes back into your (locally modified variant of the) file.) And if
you really want to dig in the history of your project, you can ask the
VCS, which you are going to need anyway for other historic information.

Regards

Markus

Hi

Jim C. Nasby wrote:
> I understand the argument about metadata and all, and largely agree with
> it. But on the other hand I think a version identifier is a critical
> piece of information; it's just as critical as the file name when it
> comes to identifying the information contained in the file.

If you really want the files in your releases to carry a version
identifier, you should let your release process handle that. But often
enough, people can't even tell the exact PostgreSQL version they are
running. How do you expect them to be able to tell you what version a
single file has?

For the developers: they have all the history the VCS offers them. There
are tags to associate a release with a revision in your repository. And
because a decent VCS can handle all the diff'ing, patching and merging
you normally need, you shouldn't ever have to process files outside of
your repository.

So what exactly is the purpose of a version identifier within the file's
contents? For whom could such a thing be good for?

Regards

Markus

Martin Langhoff wrote:
> So - if you are committed to providing your gateway long term to
> Florian, I'm happy to drop my gateway in favour of yours.

> (Florian, before basing your code on either you should get a checkout of
> Aidan's and mine and check that the tips of the branches you are working
> on match the cvs branches -- the cvsimport code is good but whereever
> CVS is involved, there's a lot of interpretation at play, a sanity check
> is always good).

Sorry for responding so late - I was rather busy during the last 1 1/2 weeks
with university stuff, and had only very little time to spend on SoC.

I've tried to switch my repo to both git mirrors, but there seems to be
something strange happening. The checkout pulls a _lot_ of objects (
a few hunder thousands), and then takes ages to unpack them all, bloating
my local repository (Just rm-ing my local repo takes a few minutes after
the checkout).

It seems as if git pulls all revisions of all files during the pull -
which it shouldn't do as far as I understand things - it should only
pull those objects referenced by some head, no?

The interesting thing is that exactly the same problem occurs with
both if your mirrors...

Any ideas? Or is this just how things are supposed to work?

greetings, Florian Pflug

* Florian G. Pflug <fgp(at)phlo(dot)org> [070430 08:58]:

> It seems as if git pulls all revisions of all files during the pull -
> which it shouldn't do as far as I understand things - it should only
> pull those objects referenced by some head, no?

Git pulls full history to a common ancestor on the clone/pull. So the
first pull on a repo *will* necessarily pull in the full object history.
So unless you have a recent common ancestor, it will pull lots. Note
that because git uses crypto hashes to identify objects, my conversion
and Martin's probably do not have a recent common ancestor (because my
header munging probably doesn't match Martin's exactly).

> The interesting thing is that exactly the same problem occurs with
> both if your mirrors...
>
> Any ideas? Or is this just how things are supposed to work?

Until you have a local repository of it, you'll need to go through the
full pull/clone. If you're really not interested in history you can
"truncate" history with the --depth option to git clone. That will give
you a "shallow repository", which you can use, develop, branch, etc in,
but won't give you all the history locally.

Also - what version of GIT are you using? I *really* recommend using at
least 1.5 (1.5.2.X is current stable). Please, do your self a favour,
and don't use 1.4.4.

a.

--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.

Aidan Van Dyk wrote:
> * Florian G. Pflug <fgp(at)phlo(dot)org> [070430 08:58]:
>
>> It seems as if git pulls all revisions of all files during the pull -
>> which it shouldn't do as far as I understand things - it should only
>> pull those objects referenced by some head, no?
>
> Git pulls full history to a common ancestor on the clone/pull. So the
> first pull on a repo *will* necessarily pull in the full object history.
> So unless you have a recent common ancestor, it will pull lots. Note
> that because git uses crypto hashes to identify objects, my conversion
> and Martin's probably do not have a recent common ancestor (because my
> header munging probably doesn't match Martin's exactly).
Ah, OK - that explains things.

>> The interesting thing is that exactly the same problem occurs with
>> both if your mirrors...
>>
>> Any ideas? Or is this just how things are supposed to work?
>
> Until you have a local repository of it, you'll need to go through the
> full pull/clone. If you're really not interested in history you can
> "truncate" history with the --depth option to git clone. That will give
> you a "shallow repository", which you can use, develop, branch, etc in,
> but won't give you all the history locally.
I'll retry with the "--depth" option - I'm doing development on my powerbook,
and OSX seems to cope badly with lots of little files - the initial unpacking
took hours - literally..

> Also - what version of GIT are you using? I *really* recommend using at
> least 1.5 (1.5.2.X is current stable). Please, do your self a favour,
> and don't use 1.4.4.
I'm using 1.5.0 currently - it was the latest stable release when I began
to experiment with git.

greetings, Florian Pflug