[kepler-dev] breaking off a kepler-docs repository

[Chad Berkley]

That is definitely the point and has been the point since we started 
checking stuff in like this.  We used to have a 'pubs' repository where 
all of the publication stuff went but we opted out of having that around 
because we wanted the pubs to go with their respective projects.  This 
works fine until it starts taking 10 minutes to checkout kepler, 8 of 
those being powerpoint presentations and word documents.

As for updating, i definitely do this, however i have 4 different 
instances of kepler on my machine right now, all in various states of 
disrepair, so it's important to me to be able to check out new copies of 
the repository in a timely fashion.

Shawn's idea of using a document system is a good one, but I know 
virtually nothing about these systems.  It would be one more server that 
we'd have to run and maintain, whereas CVS is a known quantity that we 
already have setup.  One idea is we could root the kepler repository in 
a slightly different way.  Say kepler/dev and kepler/pubs.  That way if 
you only want the code part you could do 'cvs co kepler/dev'  If you 
want it all, you would do 'cvs co kepler'.  Just a thought.

chad

Laura L. Downey wrote:
> I thought the point was having everything in one place -- which is important
> with a distributed project.  At least that is the impression I've gotten
> from Matt.
> 
> It would seem that people are "checking out" instead of "updating" with CVS
> because update is much quicker.  But I think I remember Dan telling me the
> other day that it is "safer" to check out than to update.
> 
> I'm fine with whatever is decided, keeping things together or splitting them
> apart.  My only comment is that the more repositories we have and the more
> places we have to go to get and put data (docs, code etc), the more upkeep
> that is for everyone.
> 
> Laura L. Downey
> Senior Usability Engineer
> LTER Network Office
> Department of Biology, MSC03 2020
> 1 University of New Mexico
> Albuquerque, NM  87131-0001
> 505.277.3157 phone
> 505.277-2541 fax
> ldowney at lternet.edu
>  
> 
> -----Original Message-----
> From: kepler-dev-bounces at ecoinformatics.org
> [mailto:kepler-dev-bounces at ecoinformatics.org] On Behalf Of Shawn Bowers
> Sent: Thursday, August 04, 2005 12:02 PM
> To: Chad Berkley
> Cc: Kepler-Dev
> Subject: Re: [kepler-dev] breaking off a kepler-docs repository
> 
> 
> I think it is a good idea to *not* include the various publications and 
> presentations concerning Kepler in the code repository (cvs).
> 
> I wonder, however, if having a separate cvs for documents is the way to 
> go.  Instead, maybe we should consider using a more traditional approach 
> like a document management system? I'm sure there are a number of 
> open-source/free ones out there (e.g., zope and plone are popular ones, 
> the stanford publication server is an older one).  Perhaps there are 
> also extensions of the wiki for this?
> 
> 
> -shawn
> 
> 
> 
> 
> Chad Berkley wrote:
> 
>>Hi all,
>>
>>As I sit here checking out kepler (again), waiting forever for the docs 
>>directory to finish, it occured to me that it might be ok to have a 
>>different cvs repository for kepler docs.  there's no reason why a 
>>developer should have to checkout out a myriad of .doc and .ppt files 
>>everytime you need a new version of kepler.  It seems to me that docs 
>>that actually go with the kepler software should stay in the kepler 
>>repository, but publications, reports and the like could be stashed 
>>somewhere else.  Anyone have any reasons why this would be a bad idea?
>>
>>thanks,
>>chad
>>_______________________________________________
>>Kepler-dev mailing list
>>Kepler-dev at ecoinformatics.org
>>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> 
> 
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> 
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev