[Top][All Lists]
[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: |
Lee Sau Dan |
Subject: |
Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not |
Date: |
05 Mar 2002 10:27:37 +0100 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 |
>>>>> "Christian" == Christian Andersson <address@hidden> writes:
Christian> Since cvs is a Version System, (sometimes only a single
Christian> program, and sometime it is set up as a client server
Christian> system) it keeps track of different version of files,
Christian> and what do I have, I have different versions of files,
Christian> some older ones should be used with together with older
Christian> versions of other files.
I used to use CVS to store 3rd-party jar files during a 1+ year Java
development project that I managed. I keep them in a "lib" directory,
and use "-kb" to put them into CVS. This way, I can be very sure that
every snapshot I've tagged will work the same way as when it was
tagged. CVS also lets me write log messages to explain why we
upgraded some of the JAR files, and what versions (the 3rd party's
version number) they are.
Of course, there are some considerations in terms of efficiency.
1) File size. The JAR files that I manged in CVS are quite small in size.
They are less than 1MB.
2) Update frequency. Usually, during a certain phase of development,
I refrain from upgrading the libraries (so as not to introduce new
variations on the environment). Only when the library has got a
very very important bug-fix that we deadly need, will I have a library
update within a phase. And I would announce it to all developers so
that they will retest their code against this. From phrase to phrase
(which is months part), I may upgrade to a newer version of the library.
Since the file size is not large, and the JAR files under CVS are not
changed frequently, I don't think CVS is unsuitable here. At least,
the version control part makes life much easier to reproduce any
snapshot.
Christian> BUT they can be stored in cvs, if we are not supposed
Christian> to do so, then why let us?
I agree! My advice is: don't over-do it. You know that it is
inefficient. So, don't do that too often.
>> 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.
Christian> That might be a possible sollution, but unlike
Christian> libraries and dll files it is easy for several versions
Christian> of a jar file to exist within one machine without them
Christian> competing with each others, with for example microsoft
Christian> (urgh) and dll files this is not so, if you try to
Christian> access a dcom component in that system there is only
Christian> one version of that component,you cannot (afaik) have 2
Christian> versions of the same dcom component registered. Also
Christian> there is one more difference, Dll components know there
Christian> version, not all jar-files know theirs and there is not
Christian> ONE system to ask for this information, like there is
Christian> with dll files.
Yeah! These are problematic. Not only JAR, but also RMI do not have
version info as a compulsory requirement. (How could Sun have done
that with RMI, given that they have RPC to copy from?)
>> 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?
When I see it fit. Period!
My credit card is also designed to server a very very specific
purpose. But when I can't a ruler nearby and I need one, why not use
that plastic object from purse as a ruler?
Christian> Not designed to? then my english must not be that good,
Christian> here I thought cvs stood for concurrent version system,
Christian> a system that manages to keep track and controle
Christian> different versions of files.
But _mainly_ text files which do not differ a lot from version to
version. At least, the implementation makes this assumption and
optimizes on it. The support for binary files is just a "refuge" just
in case you need to keep binary files.
Christian> and what was my problem?
Christian> well i have different versions of files and I need to
Christian> control/keep track of them.
If all your files are 30MB binary files, then CVS won't do you
anything better than manually appending a version-id to the name of
your file and using a README file for storing the revision log
messages. If you can't 'diff' and 'merge', why are you using CVS?
(
I did have some discussions with some colleagues from another team who
intended to store MSWord .doc files with CVS. My team uses XML --
text files -- and hence CVS works well. I often 'diff' them. But
with MSWord .doc files, what are you supposed to do? A 'diff' or
'merge'? Haha... These were the question I raised during the
discussions. If you can't even 'diff' or 'merge', then why are you
using CVS? What's CVS good for? If all you want is just storing
different versions and possibly attaching a description for each
version, then store them under systematically different names and
describe them with a README file!
)
Christian> I need to control that the
Christian> developers are using the newest files to work with,
Not always newest. Consider a developer working on a bug on an older
(but released) version. He may want the older version (at the release
time) of all the file instead of the newest.
In a nutshell, the *correct version*, not necessarily the newest.
Christian> if cvs can lessen our time doing manually stuff, why
Christian> not use it.. and cvs can do this.
I agree with you here. Given the 2 conditions on your JAR files under
CVS, I don't think it is a big problem. If that constitutes less than
5% of all your files controlled under CVS, either by size or by
number, then I don't think you'd be better off finding a "saner" way
of storing those 3rd-party JAR files. However, when you have so many
such JAR files that they take up >30% of your repository, then that's
heavy-duty enough to consider a tool that can manage binary files
better. It's just a tradeoff in the practical scenario. Of course,
purely theoretically, we should never ever use CVS for any bit of
binary file. But practically, I find it acceptable for a few
infrequently changing, small JAR files from 3rd parties.
Christian> There are other
Christian> version systems out there that can do this also, but
Christian> many of them are very expensive, and some cannot be
Christian> used un such a variety of different operating systems
Christian> (I am using win2k, an other developer is using linux)
And they may not be as flexible and stable as CVS! (The command line
CVS tool is very very important! You can write scripts to do many
useful things out of it. I would thus avoid those that don't even
provide a command line interface.)
--
Lee Sau Dan 李守敦(Big5) address@hidden(HZ)
E-mail: address@hidden
Home page: http://www.informatik.uni-freiburg.de/~danlee
- Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not, (continued)
- Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not, Noel Yap, 2002/03/07
- Message not available
- Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not, Lee Sau Dan, 2002/03/06
- Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not, Noel Yap, 2002/03/07
- Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not, Sau Dan Lee, 2002/03/07
- Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not, Noel Yap, 2002/03/06
- Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not, Paul Sander, 2002/03/06
- Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not, Greg A. Woods, 2002/03/06
- Message not available
- Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not, Lee Sau Dan, 2002/03/07
- Message not available
- Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not,
Lee Sau Dan <=
- Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not, Noel Yap, 2002/03/06
- Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not, Greg A. Woods, 2002/03/06
- Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not, Noel Yap, 2002/03/07
- Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not, Noel Yap, 2002/03/06
Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not, Lee Sau Dan, 2002/03/05
Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not, Richard Caley, 2002/03/05