[Tfug] Version Control

[Bexley Hall]

Hi Glen,

>>> If you are looking for a monithilic VCS that internally knows
>>> about every imaginable file type ever created, or envisioned,
>>> I suggest that you seek suggestions from somewhere other than
>>> a Unix mailing group.
>>
>> I didn't ask for a VCS that did all of those things.
>
> You may not have meant to say that, but that is exactly what it
> sounds like you asked for.

I surely don't want a VCS that *only* does "text"!  Supporting
callouts from the VCS is "old news".  CVS did it for some
versioning actions (which is what gave me the idea to modify
cvs to do it for diff, as well).

So, just saying your VCS *can* do that sort of thing is
pretty much like saying "my new computer *can* run a program
that optimizes food production to end world hunger -- because
it is designed in such a way that the existing software
(vi) can be readily replaced".

Should I claim my automation system *can* control any home
appliance or control system because of certain hooks I've
included in the design?  Or, do I gain more credibility
by saying:  "Here's the schematic/artwork/firmware for the
board that I use to instrument my washing machine -- Model
123.  Here are photos as to where you tie the various
leads into the existing machine's electronics.  And here
is the software that drives the interface.  If your machine
is different, supports more wash cycles, etc. then your
mileage *will* vary!"  And, repeat this for the dryer,
garage door opener, irrigation system, furnace/AC/cooler,
etc.

You can argue that the VCS's mentioned *have* done this:
for text, only.  Sort of like me defending my automation
system by saying, "Here's how you hook a doorbell (*button*)
up to the system..."

("Here's a list of prime numbers:  2, 3, 5, 7, 11...  The rest
are up to you to fill in...")

If the folks *using* that VCS are preoccupied with "writing
code", chances are, it *may* evolve wonderful features for
supporting "code writing" but probably NEVER will develop
even rudimentary practical features for maintaining spreadsheets!

Would you use a web browser that presented every inline
reference as a "text link" (no pictures, etc. -- i.e. lynx(1))?
Or, that supported plugins but, for which, none were available?
(Or, would you "keep looking"?)

>> But, I sure as hell don't want a VCS that thinks everything
>> other than "source code written in USASCII" is not worth
>> versioning!
>
> No one said that these version control systems won't version
> anything except for code written in USASCII.

Again, you're assuming versioning is just "storing files and
changelogs".  If that's all you expect it to be, then elide the
"diff" and "merge" capabilities from $FavoriteVCS and tell me
how wonderful it is!

EVERYONE realizes that supporting diff and merge are "object
specific" operations.  Saying you have hooks to support
those extensions is effectively meaningless (if no one is using
them!)

> Do you realize that you have changed your requirements at least
> two times since you started this thread?

No, I don't see that.  I've gone through my previous posts
*carefully*:

I see talk of repository size (my idea of "big" being probably
different from other folks' ideas of "big").

I see mention of my apprehension regarding "bolt on" GUI's instead
of ones created in lock step with the tool onto which they bolt
(but the GUI is still "optional").

I'm *constantly* harping on different file types and support
thereof.  But, that was my *first* stated requirement:
    "Chief among my requirements is the ability to support *any*
    file type (contents) without preconfiguring the system to
    understand a particular type of file (acknowledging that
    this can make diffs ineffective...)"
Note that this doesn't say diffs should ALWAYS be ineffective.
And, it doesn't say you *can't* configure the VCS to understand
a particular file type.

Similarly, I stress that versioning is not just used by software
developers to control "source code objects".  But, that virtually
every aspect of an organization, nowadays, requires it.  *And*,
that these groups don't operate in vacuums from one another
("sharing" being a big deal in effective use of data)

I see clarifications of what *I* assume to be part of (functionally)
a VCS -- i.e., not just storing (object,version) tuples but, rather,
having the VCS show me *why* the two objects are different (else
why have two versions of the same, exact object?)

I see my *opinion* as to how a VCS should be designed (e.g.,
using a formal DBMS instead of ad hoc "text files" -- aka
"UNIX databases").  But, I never state it as a requirement!
(I do state that a VCS shouldn't be storing metadata *in*
the objects it manages -- especially nowadays as that sort
of "efficiency hack" buys you very little)

So, if these tools are so wonderful and widely used, why
has their use, to date, seemed to solely involve (full
support for) "text objects"?

> At this point you would probably answer your question faster if
> you used all this time and energy to actually test out the VCS

Have *I* been complaining about expending lots of "time and
energy"?  One is always free to IGNORE any post he doesn't care
to spend time reading/replying!  :>

> systems available instead of arguing with what we are telling
> you.

Yes, I wonder how many of *you* have done a similar exercise?
And, why you don't have ready data to present?  Or, did you
just *pick* something that was "en vogue" without evaluating
what it would *really* mean to your investment?  ("I use <foo>
because *Bob* uses <foo>")

I'll let you know what I find, *empirically*.  Of course, there
will always be whiners trying to qualify or dismiss results
that they don't like... :>   (but, then *they* can always
conduct a similar experiment to present their counterpoints!
Or, attempt to refute my results.  This is what sales droids
do every day!  :-/ )