CVS stuff for AG

Robert Olson olson at mcs.anl.gov
Mon Oct 21 13:33:04 CDT 2002


is it going to stay in a sandbox directory? maybe also advertise via a 
cname - ag-cvs.mcs.anl.gov or something.

are there notes on local access? can we restrict anonymous access from 
certain modules, or are we going to be able to just make it all accessible 
(my vote...).

I worry a bit about the ag-src name - that's the source of one version of 
ag software, but as we add more it might not make sense (hence the name I 
used for the SF module).

--bob

At 01:16 PM 10/21/2002 -0500, Michael E. Papka wrote:
>The future distribution of AG software will be via anonymous cvs at ANL,
>we are moving off the sourceforge site (discussed many times no need to
>be rediscussed here). Justin and Tom have tested this and we think its
>ready to go, Ivan will be sending mail to ag-tech announcing this, along
>with directions. Justin and Ivan turn these instructions into a web page
>that can be put on the AG site.
>
>Mike
>
>-----Original Message-----
>From: Justin Binns [mailto:binns at mcs.anl.gov]
>Sent: Friday, October 18, 2002 4:50 PM
>To: Michael E. Papka
>Subject: CVS stuff for AG
>
>
>The CVS_ROOT is:
>
>:pserver:anonymous at pachelbel.mcs.anl.gov:/sandbox/cvs
>
>The password is blank.
>
>The relevant modules are:
>
>ag-src - the AG java sources and the helper apps.  This is what was
>'agib-1-glue' in the sourceforge repository.
>
>ag-dep - this contains two tarballs that have the linux and windows
>dependencies for building AG stuff.  notably, the ag-linux-dep tarball
>contains an entire tree suitable for building ag-src - with that tarball
>and the ag-src module, you can build the ag jar file and helper apps
>from scratch.  NOTE: this also contains the source distribution of the
>Orbacus stuff, for license compliance (at least on *some* level)
>
>ag-vic - the AG 'patched' version of UCL vic - a copy of the 'ag-vic'
>module in the sourceforge CVS repo.
>
>
>One note: the reason the dependencies are dealt with as tarballs is that
>CVS, for some undetermined reason, was corrupting certain of the .jar
>files when I tried to directly check in the tree.  If we can figure out
>why, then we can probably make it cleaner and distribute the
>dependencies as fully expanded modules instead of tarballs, but this
>method works whereas the other is currently broken.  As these
>dependencies are not likely to change much, and are basically binaries,
>I didn't think it was a big deal to do it this way.
>
>Questions/comments welcome.
>
>Justin




More information about the ag-dev mailing list