[Tfug] Version Control

[Bexley Hall]

Hi Glen,

>>> I haven't looked into exactly why they use a multiple of
>>> memory to do this, but internally they calculate a SHA1 sum
>>> on the object before adding it to the repo, and compare it
>>> against other files in order to save just the changes, and
>>> compress it.  This also serves to dedupe the repo contents.
>>
>> OK.  But, lots of things end up as BLOBs, then.  Pictures,
>> executables, test suites, non-ASCII documentation, schematics,
>> etc.  And, no way to meaningfully compare them other than to
>> say, "THIS is not THAT".
>
> The approach taken by *every* revision control system I have ever

Shirley you jest?

sccsdiff(1) -- mid 70's
rcsdiff(1) -- early 80's
cvs(1) diff -- late 80's

All showed an obvious preoccupation with *text* as somehow
being "special" (or the *only* thing that mattered!).  The
fact that "diff" was part of the command set instead of
"something you did after you checked out the two versions you
were interested in" shows how essential differences are to
the concept of version control.

So, they just handle text "internally" -- "because its easy"??
(Rather, I suspect it is "because we write code and are more
interested in seeing differences in our code than in drawings
what we made...")

> used, is that they are not responsible for meaningfully comparing
> two objects; they track changes. When you need to meaningfully
> compare them, you farm that out to an app appropriate for that
> file type.

Of course!  So, where is the support for "non source code" objects
*if* developers *are*, in fact, concerned with things other than
"just writing code" (as Tom suggests)?

I.e., one would think there would already be modules to
present differences between PNG's *within* the VCS
(esp a GUI based tool).  Ditto differences in OO documents,
gEDA schematics, etc. (note I haven't mentioned any FOR PAY
applications...)