Need help with CVS

[Locutus]

Hold your horses on external hosting, we might get what we need from Apolyton yet

We're working on getting a CVS server online but could use some assistence from people who have experience with it:

Does anyone know if there is some sort of web interface for CVS and how to get it to work? Getting CVS to work with a command line is easy enough, but then only Markos can access it. How do we make you guys access it as well? I can't really find anything on this on the CVS website...

[kaan]

Well im sad to say that this is what is available

http://viewcvs.sourceforge.net/

Its a repository browser, as far as im informed there is no write access.

If we are to handle alle communications with the version control system over the web then we need subversion instead.

http://subversion.tigris.org/

[kaan]

by the way, im likely to be wrong as im no expert on the subject

[kaan]

this might work though

http://list-archive.xemacs.org/xemacs-beta/199812/msg00611.html

[Fromafar]

No experience with CVS, unfortunately. If you are looking for a GUI, you may try http://www.wincvs.org/.

[ctplinuxfan]

Re: Need help with CVS

Hi,

Originally posted by Locutus
Does anyone know if there is some sort of web interface for CVS and how to get it to work?

Sorry, i know no good web interface for this, because most are designed for browsing only. The main problem for a full featured web interface is performing an update or a checkout, i.e. syncing all local copys with the newest from the repository, which has nobody solved so far afaik. Though, the most complete web interface i know is SandWeb.

Originally posted by Locutus
Getting CVS to work with a command line is easy enough, but then only Markos can access it. How do we make you guys access it as well? I can't really find anything on this on the CVS website...

For CVS, you have these options:[list=1][*]run as a pserver pserver HOWTO[*]tunnel through ssh ssh howto[/list=1]

Did you also think about subversion? Pros for subversion:

• firewall friendly (accessible through http/webdav with apache2/mod_dav_svn)
• atomic commits
• efficient binary file handling
• supports file renames
• excellent cross-platform support

VCS Comparison (Aegis/arch useless for our purposes):
CVS and Subversion comparison table
Edit: forgot the Better SCM-Comparison, if you don't click on a link of the below links by accident
I don't think other VCS systems are useful for us, so just FYI:
The most common VCS, Even more SCMs for linux, also commercial ones.

I will also be ready with the first import of the import of the Altered source files thread into subversion soon, so you could then have a dump if you wish (quite some revisions before 05.06.2004 23:13:01 will be missing, but it's complete from that time on).

If you have any questions, feel free to ask.

[Locutus]

Guys, what is your impression of Chora, would that do? We already have some Horde software installed on Apolyton and have very good experiences with it, which makes Chora very attractive to use for us.

[kaan]

Well chora looks splendid for what it does, it is one of the better web CVS reposetory browsers and i very much respect the horde framework.

It does however not fill our need for version control.
It would be a pain to sit and save each file by hand when you want to get the latest changes.
Apart from that i cant see how we are going to commit new changes to the repository.

The easy way through this would be to make a system account to witch we can log in, but i guess that it would be too much risc.

[Locutus]

Does subversion allow for commiting changes through a web interface? I can't find much info on this but what little I did find seems to suggest it can't.

[kaan]

Originally posted by Locutus
Does subversion allow for commiting changes through a web interface? I can't find much info on this but what little I did find seems to suggest it can't.

Yes it does but it requires apache 2 to do the job.
Subversion actually has more features through the http daemon than through the normal daemon.

Here's a few links:

This is for the book:

http://svnbook.red-bean.com/

This is for the pages that describes the http daemon:

http://svnbook.red-bean.com/svnbook/ch06s04.html

I hope that this info is of use.
Klaus

[ctplinuxfan]

Does subversion allow for commiting changes through a web interface? I can't find much info on this but what little I did find seems to suggest it can't.

AFAIK, Web interfaces to VCS are designed for viewing a repository, not for applying changes to it (this also applies to subversion). subversion supports WebDav/DeltaV, but i don't have a WebDav client, so i didn't test it. Is there a reason you strictly want a web interface?

Anyhow, forgot links on setting up subversion server:
SVNBook. For the rarer case setting up a apache2 hosted subversion server while keeping a apache1 main site, see here.

The user setup is straightforward for both subversion and cvs, install client and enter repository location/select access method.

PS: IMHO a web interface only makes sense for code review anyway, for it can't provide all benefits through the gui (e.g. updating local copies by only transfering differences, check out everything, using integrated solutions or programs like AnkhSVN, TortoiseSVN, WinCVS, etc.).

[kaan]

Originally posted by ctplinuxfan

AFAIK, Web interfaces to VCS are designed for viewing a repository, not for applying changes to it (this also applies to subversion). subversion supports WebDav/DeltaV, but i don't have a WebDav client, so i didn't test it. Is there a reason you strictly want a web interface?

Anyhow, forgot links on setting up subversion server:
SVNBook. For the rarer case setting up a apache2 hosted subversion server while keeping a apache1 main site, see here.

The user setup is straightforward for both subversion and cvs, install client and enter repository location/select access method.

PS: IMHO a web interface only makes sense for code review anyway, for it can't provide all benefits through the gui (e.g. updating local copies by only transfering differences, check out everything, using integrated solutions or programs like AnkhSVN, TortoiseSVN, WinCVS, etc.).

as far as i can tell WebDav/DeltaV is for both getting and updating the repository and it is supported by alle subversion clients i have heard of.
From the client side the difference is subtle and easy to overlook as the client just use a different URL specifying http as protocol.
From the server side the difference is enormous and i think that this might be just what you are looking for.

[Locutus]

Okay, what options are possible for remote access to a VCS server (either CVS or Subversion or even something else altogether) aside from a web interface? Note that security is an important concern for Apolyton, which means a pserver is as far as I can tell not an option. SSH might be an option, I'll look into that and discuss it with Markos. What other options are there, if any?

[kaan]

Originally posted by Locutus
Okay, what options are possible for remote access to a VCS server (either CVS or Subversion or even something else altogether) aside from a web interface? Note that security is an important concern for Apolyton, which means a pserver is as far as I can tell not an option. SSH might be an option, I'll look into that and discuss it with Markos. What other options are there, if any?

thats pretty much it i think.

pserver or svndaemon is the conventional way to offer vcs anonymously or with normal build in authentication.
This requires an open port in the firewall to function.

If desired it is possible to add other forms of authentication such as ssh and maybe kerobos. I dont know the details but I think that it would give the users shell access as well.
This requires the firewall to be open to ssh or whatever method is being used.

Subversion offers the ability to access a repository via webserver and use the build in authentication (on a directory basis even) without the creation of a shell account.
This may or may not require another port to be opened in the firewall. It depends on what version af apache apolyton is running now or if they might be willing to upgrade the whole site if it is needed.

It all boils down to what program marcos trust the most, if any.

[ctplinuxfan]

Originally posted by Locutus
Okay, what options are possible for remote access to a VCS server?

For CVS, options are:

• pserver via inetd/xinetd, run as non-priviliged user
  Port 2401,
  insecure
• ssh tunneling cvs communication
  Port 22, shell accounts with group write privileges to repository,
  insecure if you don't consider all users to be "trusted"
• like before, but using disabled accounts with ssh2 keys, and a COMMAND entry in ~/.ssh/authorized_keys running the pserver (maybe complicated for windows client setup),
  more secure
• chrooted pserver via cvsd (optionally with ssh accounts like before),
  more secure
  Port 2401/TCP
• chrooted pserver + ssh access through ssh+smrsh,
  also more secure

The last 2 options are the most prefered setups so far afaik, so i posted their links already.

For subversion:

• run subversion server via inetd/xinetd
  Port 3690/TCP and 3690/UDP,
  perhaps a bit less insecure than standalone cvs pserver
• run subversion server as standalone daemon process
  Port 3690/TCP and 3690/UDP, faster response than first option,
  same security level like before
• tunnel via ssh (local users, same like cvs+ssh)
  Port 22, shell accounts with group write privileges to repository,
  insecure if you don't consider all users to be "trusted"
• serve through apache2 via mod_dav_svn
  Port 80 or any other port,
  can be made as secure as a web server can be hardened, benefits of apache auth modules, optional ssl encryption
• same like before (apache2 + subversion), but a running apache1 server proxies requests
  (internet -> DMZ -> apache1 -> apache2+subversion bound on localhost: portxyz or standalone server in DMZ),
  almost same security like before (additional apache1 threat )

All but the last scenarios should be in svnbook (link posted before).
The last is a good compromise scenario if you have an apache1 host you don't wish to migrate yet, but still want the benefits of a subversion repository served by apache2. And if you decide to migrate all to apache2 later, you have a testing oppurtunity as well. The link to this is the last here link in my previous post.

PS: Sorry, if my english isn't so good or sounds a bit rough, i think i need a vocabulary upgrade...