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: Wed, 6 Mar 2002 16:52:25 +0100

----- Original Message -----
From: "Lee Sau Dan" <address@hidden>

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

I know, but do not blame me :-) I'm just trying to do my best with what I
have at hand...

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

That is true

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

but it might be better to do it with cvs then handling it all manually. IF
we
were forced to use a different versioning tool for binary files, then why
should we not use this one for sources also?  small firsm that cannot afford
to buy these commercial sollutions OR want to use CVS are either
forced to invent there own versioning system (and why not use that for
sources also), handle versioning for binary files manually (takes to much
time
and resources and produces more errors) or finally settle for the fact that
cvs can be used for binaries also, although not as good as for ascii 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).

Hmm diff/merge, one short question, as you might have understood
Linux/unix and it's tools are not my main expertise .-)

Does not linux come with a diff-tool?
Is not that difftool used by cvs?

If so, if you have 2 full versions of the same file on the harddisk and run
this
difftool would not the output of that difftool be the same as what cvs will
give you?

in the end, you can still use diff/merge even without cvs, however
cvs does this for you, and it keeps the files smaller on the harddisc...


That last there is not really any better, since if you are a couple of
persons, you
would have to copy/move/rename/diff/merge manually ?  since the filename and
where it is stored is important to java....

Even if it was only myself doing something for personal usage, I still would
use some
sort of versioning tool, since it would allow me to go back in history when
I make a
total ass of myself and produce something really stupid .-)
But the more persons there are involved the better is versioning working..



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

That is true, but unfourtunally that is not something we can choose ourselfs
that easlily
.-(






reply via email to

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