CVSup

Started by Maurice Gittensover 27 years ago13 messages
#1Maurice Gittens
mgittens@gits.nl

Hi,

I don't understand the problem CVSup is intended to solve given
that CVS allows remote access to the repository using standard cvs
commands. Is there a specific reason why we can't/don't have readonly access
to the postgresql repository?

I think it's neat to be able to use commands like "cvs diff" etc. However
I really hate it that my changes seem to get overwritten why I using
CVSup since this doesn't happen when using the "cvs update".

Can anyone explain why this is the way it is?

Thanks, with regards from Maurice.

#2Brett McCormick
brett@work.chicken.org
In reply to: Maurice Gittens (#1)
Re: [HACKERS] CVSup

This may be the totally wrong place for asking this question, but what
exactly *is* CVSup?

On Fri, 1 May 1998, at 08:36:05, Maurice Gittens wrote:

Show quoted text

I don't understand the problem CVSup is intended to solve given
that CVS allows remote access to the repository using standard cvs
commands. Is there a specific reason why we can't/don't have readonly access
to the postgresql repository?

I think it's neat to be able to use commands like "cvs diff" etc. However
I really hate it that my changes seem to get overwritten why I using
CVSup since this doesn't happen when using the "cvs update".

Can anyone explain why this is the way it is?

Thanks, with regards from Maurice.

#3The Hermit Hacker
scrappy@hub.org
In reply to: Maurice Gittens (#1)
Re: [HACKERS] CVSup

On Fri, 1 May 1998, Maurice Gittens wrote:

Hi,

I don't understand the problem CVSup is intended to solve given
that CVS allows remote access to the repository using standard cvs
commands. Is there a specific reason why we can't/don't have readonly access
to the postgresql repository?

I think it's neat to be able to use commands like "cvs diff" etc. However
I really hate it that my changes seem to get overwritten why I using
CVSup since this doesn't happen when using the "cvs update".

Can anyone explain why this is the way it is?

When I set things up, I could find no instructions for setting up
anon-cvs that I felt comfortable implementing from a security
standpoint...

If you remove the 'tag=.' part of the CVSup config file, you can
pull down the complete CVS repository to your machine to manipulate as you
want to...

#4The Hermit Hacker
scrappy@hub.org
In reply to: Brett McCormick (#2)
Re: [HACKERS] CVSup

On Thu, 30 Apr 1998, Brett McCormick wrote:

This may be the totally wrong place for asking this question, but what
exactly *is* CVSup?

See ftp.postgresql.org:/pub/CVSup ...

Show quoted text

On Fri, 1 May 1998, at 08:36:05, Maurice Gittens wrote:

I don't understand the problem CVSup is intended to solve given
that CVS allows remote access to the repository using standard cvs
commands. Is there a specific reason why we can't/don't have readonly access
to the postgresql repository?

I think it's neat to be able to use commands like "cvs diff" etc. However
I really hate it that my changes seem to get overwritten why I using
CVSup since this doesn't happen when using the "cvs update".

Can anyone explain why this is the way it is?

Thanks, with regards from Maurice.

#5Rasmus Lerdorf
rasmus@lerdorf.on.ca
In reply to: The Hermit Hacker (#3)
Re: [HACKERS] CVSup

When I set things up, I could find no instructions for setting up
anon-cvs that I felt comfortable implementing from a security
standpoint...

If you use a semi-recent version of CVS, set the --allow-root restriction
in inetd.conf and create a cvs "passwd" file along with a "writers" file,
then I really don't see where the security problem is. You are not
creating system-level accounts, and if you do not put the anonymous user
in your "writers" file, then this user will not be able to alter the
repository in any way.

-Rasmus

#6Maurice Gittens
mgittens@gits.nl
In reply to: Rasmus Lerdorf (#5)
Re: [HACKERS] CVSup

-----Original Message-----
From: The Hermit Hacker <scrappy@hub.org>
To: Maurice Gittens <mgittens@gits.nl>
Cc: hackers@postgreSQL.org <hackers@postgreSQL.org>
Date: vrijdag 1 mei 1998 19:34
Subject: Re: [HACKERS] CVSup

If you remove the 'tag=.' part of the CVSup config file, you can
pull down the complete CVS repository to your machine to manipulate as you
want to...

What way would suggest to keep in sync with the changes other folks are
making? I mean, if I have the repository on my local system I still have to
get changes changes merged in from the "main" postgresql repository.
When I think about it all solutions seem more clumsy (and less flexible)
than simply using the standard remote access to the repository.

Could you enlighten me?

With thanks from Maurice.

#7The Hermit Hacker
scrappy@hub.org
In reply to: Maurice Gittens (#6)
Re: [HACKERS] CVSup

On Fri, 1 May 1998, Maurice Gittens wrote:

-----Original Message-----
From: The Hermit Hacker <scrappy@hub.org>
To: Maurice Gittens <mgittens@gits.nl>
Cc: hackers@postgreSQL.org <hackers@postgreSQL.org>
Date: vrijdag 1 mei 1998 19:34
Subject: Re: [HACKERS] CVSup

If you remove the 'tag=.' part of the CVSup config file, you can
pull down the complete CVS repository to your machine to manipulate as you
want to...

What way would suggest to keep in sync with the changes other folks are
making? I mean, if I have the repository on my local system I still have to
get changes changes merged in from the "main" postgresql repository.
When I think about it all solutions seem more clumsy (and less flexible)
than simply using the standard remote access to the repository.

Could you enlighten me?

If you pull down the repository using CVSup into
/usr/local/cvsroot, for example, and set your CVSROOT environment variable
to point to that, you access the same thing that everyone with commit
privileges has access to, except you don't have commit privileges...

In one sense, this is better...you don't have to deal with the lag
of connecting to the remove CVS server every time you want to look at a
log or a diff...the only time you have to "re-sync" with the remote server
is when you want to pull down any recent changes, which, if you follow the
committers mailing list, you do when you notice a rash of changes...

A dialup PPP user is better served by pulling own theh whole CVS
repositiry and then being able to disconnect/work then using CVS directly
where you need to be connected to do anything...

#8Kent S. Gordon
kgor@inetspace.com
In reply to: Maurice Gittens (#6)
Re: [HACKERS] CVSup

"mgittens" == Maurice Gittens <mgittens@gits.nl> writes:

-----Original Message----- From: The Hermit Hacker
<scrappy@hub.org> To: Maurice Gittens <mgittens@gits.nl> Cc:
hackers@postgreSQL.org <hackers@postgreSQL.org> Date: vrijdag 1
mei 1998 19:34 Subject: Re: [HACKERS] CVSup

If you remove the 'tag=.' part of the CVSup config file, you
can pull down the complete CVS repository to your machine to
manipulate as you want to...

What way would suggest to keep in sync with the changes other
folks are making? I mean, if I have the repository on my local
system I still have to get changes changes merged in from the
"main" postgresql repository. When I think about it all
solutions seem more clumsy (and less flexible) than simply using
the standard remote access to the repository.

1) Remote CVS is a resource pig, especially for large tree. It puts a
large load on the server. I would guess the load is easily 10x larger
for remote CVS vs CVSUP. cvs log/diff being local instead of over the
internet is great for development especially with dialup lines to the
Internet.

2) The ability to have a local copy of the 'official tree' allows for
some possible ideas to work easier. If one is making local changes
the 'official tree' could be done as vendor imports into a local tree
allowing local changes not to be overwritten.

Could you enlighten me?

With thanks from Maurice.

--
Kent S. Gordon
Architect
iNetSpace Co.
voice: (972)851-3494 fax:(972)702-0384 e-mail:kgor@inetspace.com

#9Thomas G. Lockhart
lockhart@alumni.caltech.edu
In reply to: Kent S. Gordon (#8)
Re: [HACKERS] CVSup

If you remove the 'tag=.' part of the CVSup config file, you
can pull down the complete CVS repository to your machine to
manipulate as you want to...

1) Remote CVS is a resource pig, especially for large tree. It puts a
large load on the server. I would guess the load is easily 10x larger
for remote CVS vs CVSUP. cvs log/diff being local instead of over the
internet is great for development especially with dialup lines to the
Internet.
2) The ability to have a local copy of the 'official tree' allows for
some possible ideas to work easier. If one is making local changes
the 'official tree' could be done as vendor imports into a local tree
allowing local changes not to be overwritten.

Would someone be interested in collecting CVSup information (at least
partly from the mhonarc archive)? We could/should have a chapter in the
Developer's Guide on this...

- Tom

#10Kent S. Gordon
kgor@inetspace.com
In reply to: Thomas G. Lockhart (#9)
Re: [HACKERS] CVSup

"lockhart" == Thomas G Lockhart <lockhart@alumni.caltech.edu> writes:

Would someone be interested in collecting CVSup information (at
least partly from the mhonarc archive)? We could/should have a
chapter in the Developer's Guide on this...

I would suggest looking at the CVSup pages from FreeBSD
( http://www.freebsd.org/handbook/cvsup.html ). This page along with
a similar pages for anoncvs
( http://www.freebsd.org/handbook/anoncvs.html ) are good resources
for understanding the trade-offs. CVSup was developed/maintained
mainly on FreeBSD ( a new release (15.4) was just announced).

- Tom

--
Kent S. Gordon
Architect
iNetSpace Co.
voice: (972)851-3494 fax:(972)702-0384 e-mail:kgor@inetspace.com

#11Tom Lane
tgl@sss.pgh.pa.us
In reply to: Kent S. Gordon (#10)
Re: [HACKERS] CVSup

I'd like to second Maurice's plea for plain-vanilla CVS access.
Not all of us *want* the entire Postgres CVS repository living
on our local disk; the current sources are quite sufficient.
CVS access would be better than downloading snapshot tarballs.

I looked at the CVSup pages, and while the program looks slicker
than greased lightning for its intended purpose, I'm also quite
concerned about the amount of effort needed to port it to any
non-FreeBSD system. For starters, I gotta install DEC Modula-3,
which does not claim to have been ported to HPUX. Then I get to
find out whether CVSup itself has any portability bugs. This
sounds like a lot of work for a very second-order goal.

regards, tom lane

#12Bruce Momjian
maillist@candle.pha.pa.us
In reply to: Tom Lane (#11)
Re: [HACKERS] CVSup

I'd like to second Maurice's plea for plain-vanilla CVS access.
Not all of us *want* the entire Postgres CVS repository living
on our local disk; the current sources are quite sufficient.
CVS access would be better than downloading snapshot tarballs.

I looked at the CVSup pages, and while the program looks slicker
than greased lightning for its intended purpose, I'm also quite
concerned about the amount of effort needed to port it to any
non-FreeBSD system. For starters, I gotta install DEC Modula-3,
which does not claim to have been ported to HPUX. Then I get to
find out whether CVSup itself has any portability bugs. This
sounds like a lot of work for a very second-order goal.

It is hard to disagree with this.

-- 
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)
#13The Hermit Hacker
scrappy@hub.org
In reply to: Tom Lane (#11)
Re: [HACKERS] CVSup

On Fri, 1 May 1998, Tom Lane wrote:

I'd like to second Maurice's plea for plain-vanilla CVS access.
Not all of us *want* the entire Postgres CVS repository living
on our local disk; the current sources are quite sufficient.
CVS access would be better than downloading snapshot tarballs.

The new serve is being installed on May 7th...remind me about this
afterwards...right now, the old box is pretty much at her limit with
everything she has to handle (not just PostgreSQL related)...

The new server is built and being configured right now...alot of
things should be improved, *especially* the mailing list searches shoudl
be faster :)