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

[Richard Caley]

In article <address@hidden>, Mark A Flacy (maf) writes:

Richard> Now, someone comes along and tells me every software project needs
Richard> an icon, so this here GIF has to be part of the build. Obviously I
Richard> need to version control it in sync with the source to be able to
Richard> build old versions.

maf> No, you need to keep track of the version of the icon used when you hit
maf> certain release points of your software.  

Only in the degenerate sense that every commit is a release
point. I want to be able to back up to any place I felt was worth
commiting. If I could I'd want to back up to every point where I built 
and tested the project. This ability is the core of what version
control is for to me. being able to back up to releases is an
important special case, but it is not the end of all things.

maf> Do you change the icon often during development?

Do I change the header files often during development. How long is a
piece of string? If it changes often I need versioning to keep it all
straight, if it changes rarely versioning is almost free. in either
case versioning it is a win.

maf> Are those intermediate versions of the icon worthy of
maf> checkpointing? 

<Religious dogma alert>
 Everything is worth checkpointing
</dogma>

Version control is like backups. Keep everything because if you don't
the thing you want will be the thing you thought you never would.

Richard> Solution 1 is to set up some other versioning system (software or
Richard> ad-hoc) to version control the image file. This gains me nothing and
Richard> costs me support overhead and possible errors compared to solution 2.

Richard> Solution 2 is to check the GIF file into CVS. This gains me simplicity
Richard> and reliability and loses me nothing compared to solution 1. I can't
Richard> diff the versions of the GIF anyway, so the fact that CVS won't add
Richard> this ability is not an issue.

maf> Solution 3 is to maintain the binary image files in another directory on
maf> your repository machine.  Add steps to your loadbuild scripts (which should
maf> be version controlled) to fetch the correct image and install it to the
maf> correct place.

Ie set up an ad-hoc parallel versioning system. Ie solution 1.

What do I win? Nothing. 

Imagine CVS couldn't diff source code. Ie Imagine it just stored all
versions of all files verbatim as it does for non-diffable files. I
would still use it because the most import thing it gives me would
still be there, all I would have lost would be some disk space
(uninteresting) and the ability to do version diffs with one command.

So, back in this reality, the fact that CVS can diff source code is a
good optimisation for storage and useful to save me a command or three
when I want a diff. Great. But the fct tht I don't get those small
benfits for some other types of file just reduces me to the the
imaginary case, hence I still use CVS.

If your only reason for using CVS is to get diffs, then you will think 
differently, but I would guess most people want versioning first and
diffs as a bonus.

-- 
Mail me as address@hidden        _O_
                                                 |<