On Wed, Sep 07, 2005 at 09:29:32PM +0200, Viktor Pracht wrote:
> Just store a text file in a version control system. If you want to get
> fancy, check it in as binary, so that all conflicts get reported and
> sequential editing is enforced.
> 
> Is there a reason why the number log is more important than, say, the
> latest RTL of Traversal Technology? If not, keep them in the same
> repository and back them up together.
> 
> If you are worried about long-term storage (although I doubt the
> importance of long-obsolete versions of the number log), we will have
> the Linus system:
> 
> "Real men don't make backups. They upload it via ftp and let the world
> mirror it."
>                  -- Linus Torvalds


        I agree with the most important part of this suggestion: use a plain
text file.  Actually, I'm thinking of tab-separated text records.
        For the rest, I cite long and bitter experience.
        The most precious resource any manufacturing company has is its
engineering drawings and number logs.  These are the end product of all the
money and talent the company has ever invested in product development, and
are the single essential resource for continuing to make those products.  By
the time a company matures, it has products in production and tooling on the
factory floor created by engineers and designers who often are no longer
with the company, and sometimes are no longer alive.  I've had to help check
drawings that were signed off in 1947, so that a replacement could be
ordered for a worn-out die-casting mold.  Another time I installed a test
system at a company that had just received an order for a gear needed to
restore a historic tower clock.  That drawing was signed off in 1872, and
they still had it on file.
        I've seen what happens when a number log gets corrupted, by
something as simple as using a number and forgetting to enter it in the log. 
Multiple drawings and parts with the wrong number, propagating up multiple
BOM levels.  Incorrectly ordered parts.  Production shortages.  Mixed
inventory in stock bins.  Big thick ECOs.  Late shipments.  Unhappy
customers.
        On-line writable master number logs are something brand-new, and we
need to think about what can go wrong and devise procedures to avoid
trouble.  To rephrase Murphy's Law, "The only way to avoid having things go
wrong is to remove the opportunity."

        So: I agree that the on-line number log should be in the form of
tab-separated plain text files.  This is readable and writeable on any
operating sytem, and should remain so into the indefinite future.  This
gives strong protection against obsolescence of computer hardware and
software.  It's trivially easy to write scripts to transform this format
into other formats for display and printout.
        A number log is fundamentally a table, consisting of four fields:
the assigned number, the description, the date assigned, and the name of the
person making the assignment.  Some companies add other fields, but these
four are universal.
        Number log integrity has some requirements that are different from
either business data bases or revision-controlled source code.  They require
both a coherent way of showing everyone a completely up-to-date view, and
reliable preservation of historical records back to the beginning.  There is
no conventional software tool that fits precisely; and remember, the log
must survive the obsolescence of multiple generations of computer technology
and remain maintainable.  This is one of the reasons engineering number logs
are ordinarily kept on paper.  We don't have that option.
        We may want to consider making each log entry a separate file.  This
would make it make it much easier to prevent accidental deletion or
alteration of an earlier entry.
        If we do ever get around to writing a custom log maintenance
application, I'd lean toward using the simplest and oldest Unix utilities
that can do the job.  That would maximize portability, and give us the best
chance of carrying it forward onto newer systems.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)

Reply via email to