You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by cm...@yahoo.com on 2001/04/12 19:25:37 UTC
Re: Binaries in CVS
One issue may be that each project will include ant, xerces, xalan, etc,
with the same or slightly different version.
One compromise may be to use a separate CVS only for binaries, with the
latest "released" version of each product.
Users will have to check out the project cvs and the common binaries CVS.
Benefits over checking in binaries in all projects:
- only pristine sources in all projects ( except the binary tree )
- consistent behavior and location for the binaries for all projects using
the binary tree
- less duplication and space ( and download time )
- Sam may be happy ( as gump could create the binaries instead of checking
out, so it would be as easy to build with the "latest and greatest" )
( it would also be easy for developers to do both types of builds - if the
location of the "binary" tree is configurable )
- a simple way to get the latest stable release for all jars ( a cvs
update will also get only what's changed, instead of requiring to
download and install x different tar.gz files )
Problems:
- user has to checkout 2 trees
- all projects will be forced to use the latest stable release ( but this
can be a big benefit ! )
- you may get more binaries than you need for a project
Costin
On Thu, 12 Apr 2001, Ceki Gülcü wrote:
>
> Hello,
>
> I suppose this horse was thoroughly beaten to death but I still would like to hear about the pros and cons of including binary files in CVS.
>
> The advantages are:
>
> - By including required jar files for an application, the installation becomes easier as the user does not need to fetch them herself.
>
> - Only versions of the binaries known to work with the application are under CVS. This also eases installation.
>
> The disadvantages:
>
> - CVS does not handle binaries very well.
>
> - Increased checkout overhead as the binary files need to be retrieved from the network through the CVS pserver.
>
> - The binary file under CVS control might interact with other binaries that the user has. For example, if the user has x.jar on her classpath and x.jar is also under CVS.
>
>
> Any other advantages disadvantages? How bad is the overhead of manipulating binary files with CVS? Thanks for your comments, Ceki
>
>
> --
> Ceki Gülcü Web: http://qos.ch
> email: cgu@qos.ch or ceki_gulcu@yahoo.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Binaries in CVS
Posted by Jon Stevens <jo...@latchkey.com>.
on 4/12/01 10:25 AM, "cmanolache@yahoo.com" <cm...@yahoo.com> wrote:
>
> One issue may be that each project will include ant, xerces, xalan, etc,
> with the same or slightly different version.
That doesn't really matter and is the projects decision, right?
> One compromise may be to use a separate CVS only for binaries, with the
> latest "released" version of each product.
No.
Say there is a new feature/bugfix in Ant that Turbine *has* to use. Why
limit Turbine development that way?
> Benefits over checking in binaries in all projects:
> - only pristine sources in all projects ( except the binary tree )
> - consistent behavior and location for the binaries for all projects using
> the binary tree
> - less duplication and space ( and download time )
> - Sam may be happy ( as gump could create the binaries instead of checking
> out, so it would be as easy to build with the "latest and greatest" )
> ( it would also be easy for developers to do both types of builds - if the
> location of the "binary" tree is configurable )
> - a simple way to get the latest stable release for all jars ( a cvs
> update will also get only what's changed, instead of requiring to
> download and install x different tar.gz files )
>
> Problems:
> - user has to checkout 2 trees
I have about ~40 trees checked out. A non-issue for developers IMHO.
> - all projects will be forced to use the latest stable release ( but this
> can be a big benefit ! )
-1
> - you may get more binaries than you need for a project
-1. That isn't helping improve the situation.
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org