[Tfug] Version Control

[Bexley Hall]

Hi Tom,

>>>> I.e., the folks *using* them are mostly interested in writing
>>>> and tracking changes to *source code* and little else.
>>>
>>> Well, which of these use-cases are you evaluating for?  git is able,
>>
>> Which does a *business* decide is important?  "Let's track
>> the changes in the mechanical drawings for the PC's that we
>> manufacture and not worry about the changes in the BIOS
>> that runs in them"?  "Lets track the changes in the BIOS
>> and not worry about the changes in the schematics for the
>> hardware it runs on"?  etc.
>>
>> If you're just writing code, then all you care about is the code.
>> If you're just building metal boxes, then all you care about are
>> the metal boxes.
>>
>> OTOH, if you are "delivering systems" then you care about every
>> aspect of that system!
>
> Right, so you use the tools best for the problem at hand.

Yes, but you see Version Control as a different "problem" for each
*application* of version control!  I.e., source code version control
vs. documentation version control vs. CAD version control vs. ...

I see "version Control" as a SINGLE problem -- meriting a single
tool BEST FOR (that) PROBLEM AT HAND!

VC acts as the "vault" into which your family jewels are deposited.
*It* ensures these things are "recoverable", their histories
accurately recorded, etc.  Your "value" as an organization is
largely tied up in the IP *preserved* by that VCS.

I.e., you want to be *really* confident that it works reliably.
You don't want to check something in, then try to check it out
a year later only to discover it wasn't preserved properly.
(of course!)

> You don't
> make everyone use one set of tools.  You make _everyone_ use the same
> version of Word (or OO/LO) and the track changes feature there, and

So, now I have to hope Word/OpenOffice/<whatever> has those tracking
capabilities *and* that they are as reliable at storing versions
as my "other" VC system(s) are?  How much of a priority do you think
the maker of a word processor is going to place on maintaining
accurate historical records of your documents authored with that tool?
I.e., "version tracking" is a bolt-on feature, not a core function
of that sort of product.

By contrast, a VC system's whole purpose in life is *exactly* to
accurately preserve an objects "history".

All sorts of activities require (or can potentially benefit from)
good VC.  Do you have a separate app for maintaining your cabling
maps?  Does *it* include versioning capabilities?  How do you
know what your network looked like "on June 15, 2012" (when your
system was compromised, etc.)?

Or, do you restrict your choice of tools based on whether or not
(and how *well*!) they support versioning?
     "We'll create a cable map as an ASCII text file so we can
     use <foo> VCS to track its history.  We'll just forego any
     graphical and analysis capabilities that some other tool
     offers -- because they don't support versioning!"

As you said:  pick the best tool for the problem at hand.  Don't
*burden* it by requiring it to also serve your VC needs!

> deal with those headaches for specs and other formatted documents (and
> backups!), you use some VCS for code and other tracking tools for your
> design files, and so forth.

I (currently/historically) use cvs for *everything* (that is in
electronic form).  I.e., when I start a project, the first thing
I do is create a new repository devoted exclusively to that
project (possibly importing bits from the repositories of
previous projects).  Then, everything that I use in the design
process for that project gets "checked in":  specifications,
electronic communications with clients/vendors, executables
for the various tools that I use, documents (user manuals,
service manuals, etc.) that I prepare, test suites, *results*
from individual runs of the test suites, source code, etc.

I belatedly discovered that even this is not enough!  I now
archive the disk image of the development system (especially
for any work done under Windows since Windows hides too much
crap -- registry, etc.).  And, have started mothballing
actual *hosts* since you can't be sure a given OS, set of
tools, etc. will work on next year's machines!  (try finding
a machine that has an ISA bus to accommodate some particular
weird hardware interface card;  or, a 5" floppy; or a 3"
floppy; or a genuine serial/parallel port; etc.)

I often work in "regulated" industries.  There, your entire
*process* is exposed to audit.  Early on, I made the naive
mistake of making a small, *requested*, *documented* change
to a codebase for a client.  Checked out the "delivered"
version of the sources, patched it, "make all" and sent the
result to the client for final test.

Unfortunately, I had installed a newer version of the compiler
I had used.  So, the "small change" appeared to have a
disproportionate impact on the resulting file size:
     "This was a small change that shouldn't have noticeable
      affected the size of the executable image.  Did you LEAVE
      SOMETHING OUT??"
After puzzling over it, I realized the change was a consequence
of the new compiler's different optimization strategy.  And,
I told the client exactly this.  Instead of being *pleased*:
     "Ah, so we should have *no* confidence that this image
      works AT ALL!  We can't just test what we expect to
      have changed (based on our request to you).  Nor can
      we just be content to rerun the entire regression
      suite -- we don't have any knowledge of the quality of
      code that this new compiler generates..."
I had to go back to the compiler vendor to find a "clean" copy
of the original toolchain.

As a result, *my* "process" received a fair bit of criticism
and further scrutiny, going forward.  One of the first things
I do, now, when retrieving a project from my archives is to
rebuild the deliverable(s) and compare them to archived (CVS!)
copies of the deliverables that were actually delivered!
("Hmmm... why are they *different*?")

Moral:  being able to recreate a development environment
*exactly* is very valuable!

[Of course, not everyone has the same sort of constraints on
their work environment...  YMMV]