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

[Christian Andersson]

----- Original Message -----
From: "Lee Sau Dan" <address@hidden>
>     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.

That is what we do also, keep them in a lib directory.

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

That is true, we only have one jar file that is larger then 1Mb and that is
the
oracle jdbc2 driver but since this is not updated with so many new versions
it
is not a huge concerne for us.

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

Agree, it is not as if we are creating nightly builds of all our classes
creating several jar files
and then storing the new jar fiels in the cvs...

>     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?)

(we have started to intruduce our own version functionallity in the code so
that we can ask what version of the class we are running, and thisin all the
classes we create ourselves, if we are extending a class, we first make our
own abstract class of this class that implements the Version interface, all
classes then extends this new class and thus have to implement the version
interface)

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

Good one, I use that a lot :-)
and I also use a knife as a screwdriver a lot too :-)

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

I guess this is not just to "save space"  but to actually be able to see
what changed between
different versions..

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

Well it is not photoshop files that we are versionmanaging but smaller jar
files
(as I said above the largest is oracle jbuilder 1.5Mb, he rest is at max
150Kb)

Well since I come from a windows enviroment, cvs is mainly used as a version
control system, diff/merge is not used that much by us (yet)  and we use cvs
because
was the most cost-effective we could find..

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

Ofcourse, but that is bugfixing, with developing I meant new stuff :-)

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

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

well i have not been looking at the comand line tool so much yet and
scripts.....
Uhhhm... :-)  I'm sitting on a windows machine, and unless I find and
install a shell
that is good for this, scripting in DOS is not that good :-)

/Christian Andersson