CVS stuff for AG

[Justin Binns]

I've made a few changes, along the lines below...

The machine has a cname of ag-cvs.mcs.anl.gov

The repository is soft-linked to '/cvsroot', and only that softlink is
acceptible for pserver

The module for the source is, as Ivan suggestes, 'AG' with a tag of
AG_<major>_<minor> for the version (currently, just one, AG_1_2 for AG
1.2).

To summarize:

The pserver (read-only) access to the repository is available by the
following command:

cvs -d :pserver:anonymous at ag-cvs.mcs.anl.gov:/cvsroot co <module>

The modules are:

'AG'      AG source code.  Tagged revision 'AG_1_2' has the 1.2 source
'ag-dep'  AG dependency tarballs - ag-linux-dep.tgz and ag-windows-dep.tgz
'ag-vic'  UCL VIC with all patches and such, as currently distributed with
	  the AG binary distributions

Any other thoughts/suggestions?

Justin

On Mon, 21 Oct 2002, Ivan R. Judson wrote:

> 
> > is it going to stay in a sandbox directory? maybe also 
> > advertise via a 
> > cname - ag-cvs.mcs.anl.gov or something.
> 
> I don't know what you mean by sandbox, but the plan is to use
> pachelbel.mcs.anl.gov and enable anonymous cvs on the AG modules.
>  
> > 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...).
> 
> We'll be making it all accessible, but there will be a review process
> for code that is being proposed to be committed. We'll have to be
> extremely careful about not putting broken stuff in -- this process
> allows external developers and internal developers to submit
> modifications/additions in a symmetric way, which is good for community
> vibe.
>  
> > 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).
> 
> I think the module name should be AG, 1.0 should be put in with the 1.0
> tag, and when we're ready we'll make a 2.0 branch (then we can do bug
> fixes to 1.0 and still move ahead on 2.0).
> 
> I think that makes sense, but I was up til 3:30 with Isaiah, you never
> know :-)
> --Ivan
>  
> > --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
> > 
> 
>