Current sources?

On Fri, 22 May 1998, David Gould wrote:

I have seen a few patches fly by on the list, but when I checked the
last snapshot was dated May 4th. Unhappily, CVSup is not working for me
right now. Is there a later snapshot, or should I just work with this one?

snapshot's only happen once a week unless in a BETA freeze...what
is wrong with CVSup for you though?

Oh, and who should I really direct this kind of "site admin" question to
anyway?

Me...but the list works too, since then everyone knows what is
going on (for those new *grin*)

I have seen a few patches fly by on the list, but when I checked the
last snapshot was dated May 4th. Unhappily, CVSup is not working for me
right now. Is there a later snapshot, or should I just work with this one?

Oh, and who should I really direct this kind of "site admin" question to
anyway?

Marc, Mr. scrappy, scrappy@hub.org.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

At 7:54 AM 98.5.22 -0400, The Hermit Hacker wrote:

On Fri, 22 May 1998, David Gould wrote:

I have seen a few patches fly by on the list, but when I checked the
last snapshot was dated May 4th. Unhappily, CVSup is not working for me
right now. Is there a later snapshot, or should I just work with this one?

snapshot's only happen once a week unless in a BETA freeze...what
is wrong with CVSup for you though?

Once a week? the snapshot hasn't been updated for at least
2 weeks now.
--
Tatsuo Ishii
t-ishii@sra.co.jp
--
Tatsuo Ishii
t-ishii@sra.co.jp

The Hermit Hacker <scrappy@hub.org> writes:

snapshot's only happen once a week unless in a BETA freeze...what
is wrong with CVSup for you though?

CVSup can only be used on a few platforms, and is a hell of a big job
to port to new ones, because you have to begin by porting a Modula-3
compiler. Decidedly non-trivial.

-tih
--
Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"

On Sat, 23 May 1998, Tatsuo Ishii wrote:

At 7:54 AM 98.5.22 -0400, The Hermit Hacker wrote:

On Fri, 22 May 1998, David Gould wrote:

I have seen a few patches fly by on the list, but when I checked the
last snapshot was dated May 4th. Unhappily, CVSup is not working for me
right now. Is there a later snapshot, or should I just work with this one?

snapshot's only happen once a week unless in a BETA freeze...what
is wrong with CVSup for you though?

Once a week? the snapshot hasn't been updated for at least
2 weeks now.

My error...hard coded tar into the script, vs letting it take it
from the path...fixed, with a snapshot generated later this afternoon...

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

On 22 May 1998, Tom Ivar Helbekkmo wrote:

The Hermit Hacker <scrappy@hub.org> writes:

snapshot's only happen once a week unless in a BETA freeze...what
is wrong with CVSup for you though?

CVSup can only be used on a few platforms, and is a hell of a big job
to port to new ones, because you have to begin by porting a Modula-3
compiler. Decidedly non-trivial.

I've tried to get anonCVS working, and am still working on it,
but, for some odd reason, it isn't working as expected, even with
following the instructions laid out in several FAQs :(

Try this:

cvs -d :pserver:anoncvs@postgresql.org:/usr/local/cvsroot login
- password of 'postgresql'
cvs -d :pserver:anoncvs@postgresql.org:/usr/local/cvsroot co pgsql

And tell me what it comes up with...it might just be me *shrug*

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

At 8:17 PM 98.5.22 -0300, The Hermit Hacker wrote:

On Sat, 23 May 1998, Tatsuo Ishii wrote:

snapshot's only happen once a week unless in a BETA freeze...what
is wrong with CVSup for you though?

Once a week? the snapshot hasn't been updated for at least
2 weeks now.

My error...hard coded tar into the script, vs letting it take it
from the path...fixed, with a snapshot generated later this afternoon...

Thanks!
--
Tatsuo Ishii
t-ishii@sra.co.jp

The Hermit Hacker <scrappy@hub.org> writes:

Try this:

cvs -d :pserver:anoncvs@postgresql.org:/usr/local/cvsroot login
- password of 'postgresql'
cvs -d :pserver:anoncvs@postgresql.org:/usr/local/cvsroot co pgsql

And tell me what it comes up with...it might just be me *shrug*

Works fine for me, anyway. I'm running CVS 1.7.3 over RCS 5, and it's
pulling the PostgreSQL distribution in as I type. For some reason all
the files are mode 666 (directories are 755, as per UMASK), but that's
just a minor nit I'll figure out or work around.

Is logging in really necessary, though? This is the first time I ever
use anonymous CVS, but I'd assumed it would "just work", without any
interactive specification of passwords...

-tih
--
Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"

Tom Ivar Helbekkmo <tih+mail@Hamartun.Priv.NO> writes:

Works fine for me, anyway. I'm running CVS 1.7.3 over RCS 5, and
it's pulling the PostgreSQL distribution in as I type.

The "cvs checkout" worked fine, and a "cvs update" afterwards scanned
the repository and confirmed I was up to date. Looks good! :-)

-tih
--
Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"

On 23 May 1998, Tom Ivar Helbekkmo wrote:

Tom Ivar Helbekkmo <tih+mail@Hamartun.Priv.NO> writes:

Works fine for me, anyway. I'm running CVS 1.7.3 over RCS 5, and
it's pulling the PostgreSQL distribution in as I type.

The "cvs checkout" worked fine, and a "cvs update" afterwards scanned
the repository and confirmed I was up to date. Looks good! :-)

Odd...it was doing a 'second checkout' that screwed me, where i
didn't think it worked...try doing 'cvs -d <> checkout -P pgsql' and tell
me what that does...

And, yes, password is required...

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

The Hermit Hacker <scrappy@hub.org> writes:

Tom Ivar Helbekkmo <tih+mail@Hamartun.Priv.NO> writes:

Works fine for me, anyway. I'm running CVS 1.7.3 over RCS 5, and
it's pulling the PostgreSQL distribution in as I type.

I'm at the same point using cvs 1.9 and rcs 5.7. I also see the
bug that individual files are checked out with permissions 666.
(I've seen the same thing with Mozilla's anon CVS server, BTW.
So if it's a server config mistake rather than an outright CVS bug,
then at least Marc is in good company...)

Odd...it was doing a 'second checkout' that screwed me, where i
didn't think it worked...try doing 'cvs -d <> checkout -P pgsql' and tell
me what that does...

I'd expect that to choke, because you've specified a nonexistent
repository...

Why would you need to do a second checkout anyway? Once you've got
a local copy of the CVS tree, cd'ing into it and saying "cvs update"
is the right way to pull an update.

BTW, "cvs checkout" is relatively inefficient across a slow link,
because it has to pull down each file separately. The really Right Way
to do this (again stealing a page from Mozilla) is to offer snapshot
tarballs that are images of a CVS checkout done locally at the server.
Then, people can pull a fresh fileset by downloading the tarball, and
subsequently use "cvs update" within that tree to grab updates.
In other words, the snapshot creation script should go something like

rm -rf pgsql
cvs -d :pserver:anoncvs@postgresql.org:/usr/local/cvsroot co pgsql
tar cvfz postgresql.snapshot.tar.gz pgsql

I dunno how you're doing it now, but the snapshot does not contain
the CVS control files so it can't be used as a basis for "cvs update".

regards, tom lane

PS: for cvs operations across slow links, the Mozilla guys recommend
-z3 (eg, "cvs -z3 update") to apply gzip compression to the data being
transferred. I haven't tried this yet but it seems like a smart idea,
especially for a checkout.

On Sat, 23 May 1998, Tom Lane wrote:

Odd...it was doing a 'second checkout' that screwed me, where i
didn't think it worked...try doing 'cvs -d <> checkout -P pgsql' and tell
me what that does...

I'd expect that to choke, because you've specified a nonexistent
repository...

<> == :pserver:anoncvs@postgresql.org:/usr/local/cvsroot *grin*

Why would you need to do a second checkout anyway? Once you've got
a local copy of the CVS tree, cd'ing into it and saying "cvs update"
is the right way to pull an update.

My understanding (and the way I've always done it) is that:

cvs checkout -P pgsql

Will remove any old files, update any existing, and bring in any
new...always worked for me...

PS: for cvs operations across slow links, the Mozilla guys recommend
-z3 (eg, "cvs -z3 update") to apply gzip compression to the data being
transferred. I haven't tried this yet but it seems like a smart idea,
especially for a checkout.

Geez, sounds like someone with enough knowledge to build a
'AnonCVS Instructions' web page? :)

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

The Hermit Hacker <scrappy@hub.org> writes:

Odd...it was doing a 'second checkout' that screwed me, where
i didn't think it worked...try doing 'cvs -d <> checkout -P pgsql'
and tell me what that does...

I assume "<>" means "the same path as before", in which case this is
just doing a new checkout on top of an old one, right? I've got one
of those running now, to see what happens, but I don't see why you
would want do do this. "cvs update" is the way it's supposed to be
done, once you've got the tree checked out. I know _that_ worked.

Right now, the second "cvs checkout" is running, and there seems to be
much communication going on, but no new downloading of files I already
have. Pretty much like during the "cvs update", that is. We'll see.

Ah, yes. Here we go. This looks just like the "cvs update" pass. In
fact, it seems that a second checkout on top of an existing one turns
out to behave just like a (more proper) update from within the tree.

Done now, worked fine.

I'm starting to look forward to when the CVS source tree gets into a
buildable state again! This could be a comfortable way of keeping up
to date with the current sources. Here's hoping you find a good
solution to the s_lock.h misunderstandings soon... :-)

And, yes, password is required...

I've found where it's stashed, now. I guess that means you only need
to supply it once, to do the initial checkout, and after that you
won't have to worry about it.

-tih
--
Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"

On Sat, 23 May 1998, The Hermit Hacker wrote:

On Sat, 23 May 1998, Tom Lane wrote:

Odd...it was doing a 'second checkout' that screwed me, where i
didn't think it worked...try doing 'cvs -d <> checkout -P pgsql' and tell
me what that does...

I'd expect that to choke, because you've specified a nonexistent
repository...

<> == :pserver:anoncvs@postgresql.org:/usr/local/cvsroot *grin*

Why would you need to do a second checkout anyway? Once you've got
a local copy of the CVS tree, cd'ing into it and saying "cvs update"
is the right way to pull an update.

My understanding (and the way I've always done it) is that:

cvs checkout -P pgsql

Will remove any old files, update any existing, and bring in any
new...always worked for me...

What's that? In my understanding you have to login first. Then do one
checkout. The checkout (co) creates a new directory and updates everything
at that time. If you stay in /usr/local 'co pgsql' creates
/usr/local/pgsql. Next day or week you go to /usr/local/pgsql and try
'cvs update -d'. Only the changed files will be updated on your local
disc.

-Egon

The Hermit Hacker <scrappy@hub.org> writes:

My understanding (and the way I've always done it) is that:
cvs checkout -P pgsql
Will remove any old files, update any existing, and bring in any
new...always worked for me...

Hmm. Now that I read the cvs manual carefully, it does say:

: Running `checkout' on a directory that was already built by a prior
: `checkout' is also permitted, and has the same effect as specifying the
: `-d' option to the `update' command, that is, any new directories that
: have been created in the repository will appear in your work area.

But the more usual way to do it is with "update". Maybe the "checkout"
method is broken, or has some peculiar requirements about how to
specify the repository --- ordinarily you don't need to name the
repository in an update command, since cvs finds it in CVS/Root.
I don't know whether the same is true for the "checkout" method.
Could there be some kind of conflict between what you said on the
command line and what was in CVS/Root?

Geez, sounds like someone with enough knowledge to build a
'AnonCVS Instructions' web page? :)

Actually I'm just a novice with cvs. OTOH a novice might be just the
right person to make such a page ;-). Let me see if I can gin up some
text.

Do you want to adopt the Mozilla method where there is a tarball
available with the CVS control files already in place? I'd recommend
it; my initial checkout over a 28.8K modem took well over two hours.
Admittedly I forgot to supply -z, but judging from the pauses in
data transfer, overload of the hub.org server was also a factor ...
-z would've made that worse.

regards, tom lane

Well, the upshot from here is that having done "cvs checkout pgsql"
once, I can do either
cvs update -- within pgsql
cvs -d blahblah checkout pgsql -- in parent directory
and they both seem to work and do the same thing (although with no
updates committed in the last two hours, it's hard to be sure).

If I omit the -d option to the cvs checkout, it fails; it does not
know enough to fetch the repository address from pgsql/CVS/Root.
But cvs update is cool.

Dunno why it doesn't work for Marc. I'm running cvs 1.9; you?

regards, tom lane

On 23 May 1998, Tom Ivar Helbekkmo wrote:

Ah, yes. Here we go. This looks just like the "cvs update" pass. In
fact, it seems that a second checkout on top of an existing one turns
out to behave just like a (more proper) update from within the tree.

Done now, worked fine.

Odd, must be a problem with the machine I was trying to run it
from then *shrug*

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

On Sat, 23 May 1998, Tom Lane wrote:

Do you want to adopt the Mozilla method where there is a tarball
available with the CVS control files already in place? I'd recommend
it; my initial checkout over a 28.8K modem took well over two hours.
Admittedly I forgot to supply -z, but judging from the pauses in
data transfer, overload of the hub.org server was also a factor ...
-z would've made that worse.

Can you try it with a -z and time it? I would judge it to be
faster, since the -z should be more processor intensive, and the processor
on Hub is idle most of the time. The -z would reduce bandwidth, though...

As for the CVS control files...will look at it...but even then,
its going to take awhile to download, due to the overall size of the file
in question...

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

On Sat, 23 May 1998, Tom Lane wrote:

Well, the upshot from here is that having done "cvs checkout pgsql"
once, I can do either
cvs update -- within pgsql
cvs -d blahblah checkout pgsql -- in parent directory
and they both seem to work and do the same thing (although with no
updates committed in the last two hours, it's hard to be sure).

If I omit the -d option to the cvs checkout, it fails; it does not
know enough to fetch the repository address from pgsql/CVS/Root.
But cvs update is cool.

Dunno why it doesn't work for Marc. I'm running cvs 1.9; you?

Yup, but I have a few suspicious on why it doesn't work that I'll
investigate on monday :)

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org