[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: CVS corrupts binary files ...
RE: CVS corrupts binary files ...
Tue, 6 Jul 2004 17:49:29 -0700
>--- Forwarded mail from Greg Woods:
>[ On Friday, July 2, 2004 at 12:49:58 (-0700), Paul Sander wrote: ]
>> Subject: RE: CVS corrupts binary files ...
>> >--- Forwarded mail from address@hidden
>> >[ On Wednesday, June 30, 2004 at 22:59:27 (-0700), Paul Sander wrote: ]
>> >> Subject: RE: CVS corrupts binary files ...
>> >> >(A) they're not "sources" -- they're intermediate product files.
>> >> They're not "intermediate product files" unless they can be reproduced
>> >> from some other source using an established process.
>> >Yes, they are intermediate product files. Just because their ultimate
>> >source code is managed by someone else doesn't change the fact that they
>> >are not sources for the local project -- indeed it only confirms it.
>> In other words, you're trying to integrate your vendor's CM process into
>> some global, all-encompassing process that also happens to include yours?
>Oh, come on now Paul! How much detail do I have to give you? I thought
>you had enough experience with SCM by now that you'd understand how to
>manage third party components with the appropriate tools!
I know how absurd it sounded, but I had to ask to make sure I understood
what you were saying. And you really aren't making a lot of sense.
>NO, I am not even suggesting that the vendor's CM process be accounted
>for in any way.
Whew! That's good!
>I'm saying quite simply that intermediate product files are what they
>are regardless of who produces them.
Intermediate product files are things like .o files, which are neither
sources nor shippables, but are an essential part of the overall build
process. Because they can be rebuilt at will from existing sources using
a repeatable procedure, their retention is not required and sometimes is
not even desirable.
This appears to be the basis of our disagreement: For me, "intermediate
product files," as I've defined them above, can be deleted and rebuilt at
will. Products that come from outside sources do not fit this description.
Because products from outside sources, for all intents and purposes,
cannot be re-created without human intervention, they require an archival
method that can re-create any coherent sets files supplied by the vendor
at any time. That's precisely what version control is good for, and that's
why I check in everything I receive from any vendor. By using CVS as my
only version control tool, I don't need variants of all of my other tools
that interface to version control.
Additionally, my build processes manage storage and baseline references
automatically, and they provide a consistent interface at the top level
to facilitate automated scheduling. That means that whatever build and
installation procedures that exist must have a consistent interface. In
my case, I have a limited set of hooks to allow for per-build refinements
(e.g. a Gnu compatible makefile in the top of the source tree that
implements an "all" target) and also publishes its outputs (e.g. search
paths for use by other builds, packing lists and shippables, etc.).
In this environment, it is *possible* to hand-craft baseline builds for
third-party products (as you suggest), but it is **far easier** (in the
long run) to treat them like source code because all of the power of the
existing environment is brought to bear to manage them.
>If you don't know how to track the components of your software using
>your own processes, i.e. over and above and outside of CVS, then I've
>got to wonder if you have any SCM outside of CVS. Remember CVS is not a
>complete configuration management system. I know you know that but I
>seem to have to keep pointing it out to you almost continuously.
My processes track all of the inputs to my processes. They also track
artifacts that are automatically managed (e.g. baseline references), as
well as artifacts that can't be controlled (e.g. the operating system and
patch level on the build machine). It turns out that, although such
traceability records are outputs of my build procedures, they represent
sources that cannot be automatically reproduced exactly, so they are
also checked in and become input to the tools that reproduce old builds.
>> Well, in my world, there are boxes around my process and my vendors.
>You've got to learn to think outside your box!
>(and especially to think outside of the box CVS works within)
The power convenience given to me by the contents of the box makes
compelling reason to stay inside it. Although the interfaces are fixed,
they are pretty generic. Thin abstraction layers provide sufficient
flexibility to accomodate the requirements of vendor-supplied files while
still meeting the repeatability and reproducibility (build and configure
it the same way, over and over again) requirements.
>--- End of forwarded message from address@hidden