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

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

It's sick  that everybody managing  a *real* software project  have to
reinvent this.  If  only Sun's Java team understood  the importance of
version  tracking in  JAR  files and  in  RMI definitions.   I was  so
disappointed that RMI wasn't even  an improvement over the 10+year old
RPC.  It lacking the version checking stuff that RPC has.


    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 it was designed primarily  for handling program source codes.  So,
it makes a  basic assumption that these codes  are *ASCII* text files.
(Well... Try  a UTF-16  file, and that  won't be anything  better than
binary files  to CVS/RCS.   UTF-8 and ISO-8859-1  would do  better, as
these  are  highly  ASCII-compatible.)   Many optimizations  (such  as
storing only diffs between versions) are based on this assumption.

It's  great that CVS  does not  _require_ this  assumption to  be met.
When the  assumption is  not met, then  it degrades  (gracefully), but
still works (instead of crashing or becoming crazy).  Many "commerical
quality" software nowadays  on the PeeCee market can't  even meet such
tolerance!  But  that doesn't  mean it's  a good idea  to use  CVS for
binary files.



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

Most CVS  users will disagree with  you.  For me, the  main reason for
using CVS/RCS is to be  able to diff/merge between versions.  If these
operations are  not needed, I'd simply store  different versions under
different file/directory names, so that  I can access any version much
more directly (no need to checkout/update first).


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

Windows/DOS  gives you a  very very  very confined  view of  the giant
world.


-- 
Lee Sau Dan                     李守敦(Big5)                    address@hidden(HZ) 

E-mail: address@hidden
Home page: http://www.informatik.uni-freiburg.de/~danlee