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
* Florian G. Pflug [EMAIL PROTECTED] [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
Aidan Van Dyk wrote:
* Florian G. Pflug [EMAIL PROTECTED] [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
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
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.
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
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
* Tom Lane [EMAIL PROTECTED] [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
Tom Lane wrote:
Martin Langhoff [EMAIL PROTECTED] 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
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.
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
* Jim C. Nasby [EMAIL PROTECTED] [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
* Aidan Van Dyk [EMAIL PROTECTED] [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...
Aidan Van Dyk wrote:
* Aidan Van Dyk [EMAIL PROTECTED] [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
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
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
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
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
Aidan Van Dyk [EMAIL PROTECTED] 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
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
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
* Florian G. Pflug [EMAIL PROTECTED] [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
Martin Langhoff [EMAIL PROTECTED] 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
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) ;-)
* Aidan Van Dyk [EMAIL PROTECTED] [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
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 -
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
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 +++
Alvaro Herrera [EMAIL PROTECTED] 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
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] 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
[EMAIL PROTECTED] (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
[EMAIL PROTECTED] (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 +++
* Florian G. Pflug [EMAIL PROTECTED] [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
Aidan Van Dyk [EMAIL PROTECTED] 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
* Tom Lane [EMAIL PROTECTED] [070416 19:03]:
Aidan Van Dyk [EMAIL PROTECTED] 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
Aidan Van Dyk [EMAIL PROTECTED] writes:
* Tom Lane [EMAIL PROTECTED] [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
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
Tom Lane wrote:
Aidan Van Dyk [EMAIL PROTECTED] writes:
* Tom Lane [EMAIL PROTECTED] [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
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
* Tom Lane [EMAIL PROTECTED] [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
Aidan Van Dyk [EMAIL PROTECTED] 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
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
42 matches
Mail list logo
