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

[Richard Caley]

In article <address@hidden>, Greg A Woods (gaw) writes:

gaw> The GIF does need to be part of the build, and it is something that
gaw> might change over time, but it doesn't necessarily have to be kept quite
gaw> so closely in sync with the sources (an old GIF may work fine with a new
gaw> product, just as a new GIF may work fine with an old product), and it is
gaw> not source itself either.

It's a file that goes into the build. That to me is source. But that
is also irrelevent. 

I don't _need_ to version the header files. After all they change
rarely. Maybe more rarely than the icon in a mature project. That is
not an argument for arbitrarilly excluding them from versioning. 

The new and old GIFs may work the same, in which case versioning is
wasted. My disk may not crash in which case backups are wasted. The
point is not the many times the facility is not called on but the one
time it saves your bacon.

gaw> You've got to learn to think (and climb) outside of the box you've put
gaw> yourself into.  

Sorry, I think you are arse over tit here. _You_ have arbitrarilly
decided that if CVS can't give you a diff for something then it
doesn't need version control. That sounds like I'm outside and you are 
inside. Just because the fiel fomat makes use of a certain form of
redundancy to save space, that does not mean that every use must ake
advantage of that optimisation. 

gaw> Use the right tool for the job.  

You have yet to show CVS is not the right tool for version controling
things like icons and third party jar files.

So far as I can see, and forgive me for any straw men, your arguments
against using CVS are:

        CVS doesn't optimise its disk useage for these files as
        effectively as for, say, C source.

Big deal. It's no wosre than other available methods of keeping these
files. Besides which disk is cheap.

        CVS doesn't help you diff these files meaningfully.

Lacking some other tool which does better this is not an
argument. Besides which these files are generally not ones where
automatic diffing is useful (If I antialias the text in a gif, it's
going to be a bloody clever diff programme which can tell me that is
the change, a changelog done by me when I do it is a better hope).

Yes, if file space or diffing became an issue I would look for or
build a better tool, perhaps by extending CVS. But neither is an
issue.

If you know of something which _is_ an issue, please tell me. I have
not hit it in years of using CVS.

If I had a project which was mostly, say, sound files (and I have
worked on such) and someone showed me a version system which was much
more space efficiant than CVS for sound files and gave more meaningful 
automaticly generated change information, then I might choose that,
even putting the few non-sound files in the same system even though
they didn't get the same advantages. 

Horses for courses.

If this hypothetical system could be kept in sync with CVS perhaps I'd 
use both side by side in a project where significant numbers of both
types of file were involved.

But even if it existed, in a project where there are 1000 text files
and 2 sound files, it would probably not be worth the support time to
run the second system to version that one file. The extra disk space
and the requirement for people to manually note what they changed in
that one file in the changelog are going to be far cheaper.

-- 
Mail me as address@hidden        _O_
                                                 |<