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

[Thornley, David]

> -----Original Message-----
> From: address@hidden [mailto:address@hidden
> Sent: Wednesday, March 06, 2002 3:11 PM
> To: address@hidden
> Subject: RE: CVS and Jar files: Should you import Jar into the
> Repository? Why or why not
> 
> 
> [ On Wednesday, March 6, 2002 at 14:21:56 (-0600), Thornley, 
> David wrote: ]
> > Subject: RE: CVS and Jar files: Should you import Jar into 
> the Repository?        Why or why not
> >
> > I still fail to understand the problem.
> 
> What's to UNDERSTAND?  CVS manages source files which are diffable and
> patchable.  Other things manage other kinds of files.  You 
> tie all these
> things together in whatever overall build and release management
> processes and procedures you will need for all but he most mundane of
> projects.  There are apparently even already tools that make 
> short work
> of tying these things together for Java JAR files!
> 
What's to understand?  Simply, why I should not control some binary
files with CVS.  So far, for all your rhetoric, you have failed to
actually tell me any specifics about a problem.

Further, CVS manages source files that are not diffable and patchable.
I've done it.  Other things also manage these sorts of files, but
CVS will do it.  CVS doesn't do as well with these files as with
(say) C source files, but this isn't a cause for alarm.

> > > Simple directory naming schemes are almost infinitely better!
> >
> > In what way is a directory naming scheme, or named 
> tarballs, infinitely
> > better?
> 
> It has all the features and capabilities necessary to fulfill your
> requirements for keeping many revisions of binary files, and 
> it has none
> of the drawbacks of CVS.
> 
I can keep many revisions of binary files in CVS.  Granted, a large
file with lots of changes will have a very large ,v file eventually,
and this may be an issue, but it isn't necessarily the case, and indeed
I haven't run into such a case.  The files that cause the most performance
issues in our repository are large text files with lots of revisions.

Now, it may be that CVS would have problems with large and frequently
changed files, but not all binary files are like that.  If I kept *.o
files in the repository, I'd expect problems.  As it is, the problems
caused by the binary files I've got (both at work and at home) are
less troublesome than the problems caused by the sorts of files CVS
is supposed to handle.

> >  In order for it to be infinitely better, I'd need to be causing
> > infinitely hard problems by keeping binaries under CVS control.
> 
> Unless you can securely isolate all your non-diffable and 
> non-patchable
> files in modules separate from your source files, and unless you can
> ensure all your CVS tools (client, server, etc.) properly handle all
> aspects of binary files, and unless you can securely 
> implement policies
> stating how those modules containing binary files are to be used and
> manipulated, you cannot safely use CVS in general to track 
> revisions of
> binary files.
> 
Why not?

I call them "-kb" on creation.  That seems to have protected them just
fine.  I have had no, repeat no, cases of file corruption.

> However even a simple naming scheme "just works".  That seems to be
> infinitely better to me!
> 
Although you have notably failed to provide what I asked for, namely
something in the way of use cases to show problems in using CVS to
store binaries, I'm going to discuss possible ways in which such
schemes can fail.

Suppose we have one master directory, with subdirectories specifying
branches and subdirectories below these specifying dates.  We will
assume that these directories are executable and readable for all the
developers, and writeable for an administrator.  What sorts of things
can go wrong?

1.  Somebody can make a change and fail to notify the administrator,
or the administrator can be out or otherwise occupied and fail to
record a change.  This can mean a missed change, or a misdated one.

(Note that this can be partly alleviated by allowing the developers
to add files to the repository.  I'd be scared that they'd misname or
overwrite something.  One thing CVS does is ensure that, unless
somebody has direct repository access, they are limited in what they
can do, and cannot, unless they use "cvs admin" (which you can
restrict with OS groups), lose any versions.  They can lose tags,
which is a problem, but not versions.)

2. The administrator can misname a directory accidentally, or fail
to create a new directory because the changes seem so small.  In this
model, there will be a very strong tendency to keep only versions
that seem significant, and this may cause problems later.

3.  A directory could be removed somehow and not be noticed for a
long time.  The only safe way to deal with this is to have independent
backups going back to day 1.

4.  Looking through the dated directories and finding the one with the
latest date before the intended date is tedious and error-prone, and
any failure of the directory name to match the standard form (through
mistyping or whatever) can make the job more difficult or even impossible.

5.  There is no automatic way to trace any sort of version information.
This includes knowing if the binary is indeed present in the repository.

6.  Suppose a new binary file is added to the project.  Now, either
the developer is responsible for gathering the binaries, or the
administrator
does using some sort of tool.  If the binary is overlooked by developer
and/or the administrator, it gets missed.  Since there isn't any sort
of 1-1 correspondence between the working directories and any repository,
it's hard to tell if a file got overlooked.

7.  The disk space may get tight.  Remember that in this model, we're
keeping copies of everything for every change, regardless of whether
they've changed or not.  If we can determine which files have not
changed, we can presumably substitute symbolic or hard links, but
that seems to me subject to error.

Now, can you do the same for binaries on CVS?

> Use the right tool for the job!
> 
When I've got some project I have to do, or want to do, and I don't have
the right tool for the job, it seems to me that I can either abandon
the project, drop the project for the foreseeable future while I make
the right tool, or use a tool that's not quite right.  While none of
these are ideal, it isn't clear to me that the third option is clearly
the wrong one.