info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CVS and Jar files: Should you import Jar into the Repository? Why or


From: Greg A. Woods
Subject: Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not
Date: Mon, 4 Mar 2002 20:32:38 -0500 (EST)

[ On Tuesday, March 5, 2002 at 00:35:02 (+0100), Christian Andersson wrote: ]
> Subject: Re: CVS and Jar files: Should you import Jar into the Repository? 
> Why or why not
>
> So what you are saying is that  if we are several developers spread across
> several places (perheps even different countries) and in our project we use
> 3:rd party jar-files, is that we should have second system for delivering
> these jar-files to the developers and making sure that they are all using
> the same versions?

"delivering" What can that possibly mean in this context?!?!?!  Surely
each site can all keep their own copies of these files -- they don't
change betweeen revisions, by definition!

Since Jar files are products they really should be installed as
appropriate onto the development and test machines, just as I would
install compiled C libraries (and their associated header files) on my
development machines (or the compiled shared libraries on the test and
user machines).  I don't know if it's possible with Jar files, but I
always try to arrange things so that I can have many versions of my
libraries all installed at the same time on the same machines and then I
use mechanisms in my build processes to ensure the correct revisions are
used when building a given release of my own products.

I.e. Jar files, C libraries, shared libraries (DLLs or whatever) are
just more components.  It is irrelevant whether you have source for them
or whether you build them yourself.  The are installed on the machines
and used in conjunction with your own software.  Since Jar files are
used dynamically at run time you should use run-time configuration
parameters to ensure the correct versions are found and used by a given
version of your software.

> And why should we have to use 2 different versioning systems for this, I
> agree that using cvs for storing binary files are not "cost effective", but
> using 2 different versioning systems for this is I think even worse.

Why would you try to use one tool which has a _very_ specific capability
to do something that it is explicitly not designed to do?  Why would you
insist on trying to hammer in machine screws with the handle of a
soldering iron?

> What wuld be nice to have is a developement project system that takes care
> of versioning and many more things, but unfourtunally I have not seen any
> that I like yeat, and that is not to costly. So for now cvs is a
> sollution...

Software development is done with a collection of tools that you need to
learn to use and integrated to the best of their abilities and to suit
_your_ needs.

If you want an entirely integrated development environment then might I
suggest you go find one.  They do exist, but so far as I know CVS is not
even a component in any of them.  When I want such an environment I find
the Squeak implementation of Smalltalk-80 to be very suitable for my
needs.  I'm told some of the commercial Smalltalk implementations go
even further down the road of full project managment and do even better
with assisting in the whole process of software configuration management.

-- 
                                                                Greg A. Woods

+1 416 218-0098;  <address@hidden>;  <address@hidden>;  <address@hidden>
Planix, Inc. <address@hidden>; VE3TCP; Secrets of the Weird <address@hidden>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]