[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: How well does CVS handle other types of data?

From: Greg A. Woods
Subject: RE: How well does CVS handle other types of data?
Date: Fri, 13 Jul 2001 16:23:05 -0400 (EDT)

[ On Friday, July 13, 2001 at 14:20:07 (-0500), Cameron, Steve wrote: ]
> Subject: RE: How well does CVS handle other types of data? 
> Re-reading my original message, I see I failed to mention those binary
> files were 3rd party object code for which we do not have access to 
> the source code, yet which are nevertheless required to build our product.  

OK, so what's the problem with using "-L" (and "-I" if necessary) to
simply point at the right version of that code (and headers) in the
build process!?!?!?!?!?

Putting object code into CVS is just plain silly and pointless and can
only cause problems.  Here you've got third party object code that you
can simply install in a well named directory on your build machine(s)
and be done with it!  Why fool with binaries in CVS, ESPECIALLY if
you're doing branching?!?!?!?!?  That's what I call banging your head on
the wall and then complaining about the headache!  DON'T DO THAT!!!!
(if you don't _want_ a headache, that is!)

I'm literally stunned that after all this I learn you're only talking
about handling third-party object code!  Please refer again to my
example of the Motif version handling, and to Mike Castle's example of
handling a word doc too, and all my previous rants about handling
non-mergable files by using the build process to identify related
external versions of non-mergable files!

Your particular issue with binary files and CVS is so simple and trivial
to fix that it's just not funny.  The technique I mention was probably
first discussed in this forum nearly five or six _years_ ago!  It's not
discussed in the manual because it's not a CVS issue -- it's a build
system issue!  It is discussed, indirectly, in the O'Reilly "RCS and
SCCS" book, and it's an issue common to any project using third-party
components (and tools).

(stupid and ignorant, legally speaking, license agreements aside; which
obviously you'd be voiding by putting the code into a backed up CVS repo

> Of course if you can derive a file it shouldn't go into CVS at all, 
> I didn't mean to imply otherwise.  My binaries are not derivable by me.

Yes, your 3rd-party binaries are derivable by you.  You simply go back
to the 3rd party to get fresh copies of them!

(Well, obviously you should optimise that process and make it safe and
redundant by archiving all versions of them not only on your build
machine(s), but also on stable media that you store in several safe
places, including off-site.)

                                                        Greg A. Woods

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

reply via email to

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