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: Christian Andersson
Subject: Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not
Date: Tue, 5 Mar 2002 00:35:02 +0100

> > unless ofcourse you got the jarfiles from some external source that you
do
> > not have the sourcs for, but might want to control in a "project"
anyway...
>
> Then they are part of a separate module, and using CVS for this module
> alone just for the illusion (and that's the _most_ it could ever be) of
> having them under the same control as the rest of your project is a BAD
> and extremely unnecessary idea.
>
> Certainly you should keep all the revisions of them that you have, and
> certainly you should document how they relate to your own code releases.
> You don't need CVS to do any of that though (except perhaps to track any
> changes to your text-based documentation files).

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?

For instance, in one of the companies I have worked for, we were having
exactly that problem, we were located in two different places and we were
using different versions of the mm.mysql jdbc-driver, the problem we
experienced was that while my own and theirs code worked for me, my code did
not work for them, we did not understand it right there that we were using
different versions of the jar-files for mm.mysql, if we had used a
versioncontrole system for this, we would not had this problem.. (my version
if the jdbc driver was never)

The question is then, what version control system do you think we should use
for 3:rd party jar-files, or other 3:rd party binary files that do changes
over time and we might need to use never versions because of bugs in older
versions.

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.

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...

I might be wong, and I'm willing to learn :-) but sofar this is a sollution
for me, but there is better ways of doing this (for instance one system, and
one way of doing things, instead of several) I'm ready to check it out, but
I have as said not found any yet.

/Christian Andersson




reply via email to

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