Running a RemoteCVS server
Running an RemoteCVS server is easy, all that has to be done is to run the JAR file, change one or two things in the GUI and set back to let it do it's thing. However, because it builds a program from the source code, it will use a lot of CPU cycles and will often mean that your processor is running at 100% usage, and thus other programs may run slower and feel sluggish. However, with this said, it is possible to run 3 builds at the same time and still have a usable computer (running an a single AMD 3000+ with 1 GB of RAM whilest doing other things).
The whole point of this is to enable other users to obtain the latest CVS builds as and when they want, because setting up the right enviroment can be time consuming and a royal pain in the ass at times. This does mean however that the server does need to be configured to be able to fetch the CVS code, compile programs and do anything else that may be needed.
Currently the program will only work in Windows (there is a linux version planned... later) and only as a GUI program. It also requires that some things are setup in a standard way so that everything can be found in the correct place. Below is a list of what needs to be where:
1) CygWin needs to be installed
in C:\cygwin\ (can now be installed anywhere) and it needs everything that PearPC needs to be build (check here for what's needed), and I recommend that everything in the devel brach is installed (ensures future builds will also complete ok). An extra lib is also needed, SDL. This can be downloaded from http://www.libsdl.org and the file needed is this (for the lazy people ;-) ). Once this is installed you need to create a symlink or copy them over to c:\cygwin\lib\*SDL* from c:\cygwin\usr\local\lib\*SDL* because otherwise the configure won't find them.
2) Currently the server has to run on the same machine as a webserver (i.e. you run Apache or IIS or some other webserver), and there needs to be a symlink (created in cygwin) pointing to where it is on your computer, this is my symlink as an example
ln -s /cygdrive/d/stuff/web\ sites/pearpc.sytes.net/auto-cvs/ /webserver
Note: If there is a [SPACE] in the path name then a \ is needed before the [SPACE]
3) With that created we now need to create a folder for the CVS code to be stored. This will be the master code and will never be compiled. What will happen is that the code in each of these folders will be updated when needed and then copied into another folder to be compiled.
To do this we enter CygWin and run:
cvs -z4 -d:pserver:email@example.com:/cvsroot/pearpc login
cvs -z4 -d:pserver:firstname.lastname@example.org:/cvsroot/pearpc co -r altivec pearpc
mv /pearpc /altivec
this will download the altivec branch of the source code and place it all in a folder called pearpc, then move this to another folder called /altivec so we can keep different folders for each branch. Next we went to standard PearPC code and so wee run
cvs -z4 -d:pserver:email@example.com:/cvsroot/pearpc co pearpc
Which will download the code into a folder called pearpc, which is where we want it.
4) Now we've setup CygWin, got the link to the folder for the webserver and downloaded the first update of the CVS code, all that's left to fo is create the folders /auto-cvs-builds/ and /auto-cvs-builds/logs/
This is where all the code is copied to so that there aren't hundards of folders in the root folder. The code in this folder is never deleted by the program, so you may want to delete old builds as and when you see fit. They are not deleted incase there is a problem, the users can ask about it and the code can be checked for that build and see what the output of it was. The logs folder contains a copy of all the output made by the build with a file name <uniqueID>.log
When a compile is completed then the program will copy the produced EXE to /webserver/ and if the symlink is setup correctly then the file will be available on your website.
That's the setup of CygWin complete, next the (very) few options on the server itself:
As you can see there aren't many options:
1) Max number of concurrent builds: This changes the maximun number of builds that can take place at any one time. It can be changed at any time, although any builds currently being built will continue until finished.
2) URL of the folder...: The label is a bit bad, but basicly this is the URL that will contain the completed builds. This is what's sent to the remote client with the name of their EXE added to the end, so the trailing / is REQUIRED. If a bogus URL is entered then the client will still try and go there and if it can't find the file then the user will not be able to get their build.
They are the only options that can be changed at the moment, with new versions of the program I will be adding more settings (like non-default locations of CygWin). The text area that's displayed currently has limited funcionality. It'll display listening when it's waiting for a new connection and when it gets one it'll append the clients IP to the area and then let you know that it's listening for another connection. When a new connection is made a new tab will open at the top with it's title set as the clients IP. All this new tab contains is another text area that will display what the client is seeing in their applet, and once the build is completed and the applet is closed/destroyed the tab will be removed.
Clear will remove all the text from the text area, and Close all connections currently does nothing ;-) (this will be implemented soon)
Once this is setup it can be minimsed and left alone. Should you want to close the server I would recommend setting the max number of builds down to zero and letting the current builds finish. Then close the server down and the applets should throw an exception and let the client know the server has closed down (currently also unimplemented).
And that's it for running an RemoteCVS server. If you have any questions please come on to irc.freenode.net #pearpc
NB: The initial title was Auto-CVS but was changed (people said the name sucked :) ). There are still references to Auto-CVS (suck as folder names) and these are still needed (for now) until we update the code and the docs.