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

[Lee Sau Dan]

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