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

[Greg A. Woods]

[ On Wednesday, March 6, 2002 at 16:52:25 (+0100), Christian Andersson wrote: ]
> Subject: Re: CVS and Jar files: Should you import Jar into the Repository? 
> Why or why not
> 
> From: "Lee Sau Dan" <address@hidden>
> >     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).
> 
> Does not linux come with a diff-tool?
> Is not that difftool used by cvs?

Yes and yes.  That same GNU diffutils is portable to many platforms and
is a core component on many of them.  All Unix systems available today
come with some implementation or another with similar capabilities.
Most come with an implementation of 'patch' too, but of course the GNU
Patch program is also portable to many platforms.

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

Yes.  Obviously.  What would be the point otherwise?

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

Yes of course -- and there's the rub.  CVS uses diff (and patch, the
merge tool) to store and retrieve changes from the RCS files it
maintains your revisions in.  If you can't get meaning from running diff
against two revisions of your files (or diff3 between two variants
derrived from the same ancestor), and if you can't apply the diffs to a
slightly changed file with patch, then you should NOT be using CVS for
your files.  Period.  It matters not what the Paul Sander's of the world
might claim is possible -- I speak of what _is_, right now, today.

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

Obviously!  CVS is meant to deal with thousands of source files all in
one consistent way.  It's a simple front end that automates the drudgery
of using RCS in a consistent way.

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

Sure!  Me too!  I use RCS or SCCS or CVS on almost all of the files I
keep and change on a regular basis.  I have done so for a decade and a
half, or more now.

You could do all of what any versioning tool does with pencil and paper
alone, but these tools make such tasks much less painful.  They do much
of the accounting for you and prescribe a process that makes remembering
all the necessary steps much easier too.

> But the more persons there are involved the better is versioning working..

And thus CVS was born with it's inherent design feature that effectively
requires you to allow for the possibility of concurrent edits.

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

It is far easier than you might think.  There's an entire world of
alternatives out there.

-- 
                                                                Greg A. Woods

+1 416 218-0098;  <address@hidden>;  <address@hidden>;  <address@hidden>
Planix, Inc. <address@hidden>; VE3TCP; Secrets of the Weird <address@hidden>