[Tfug] Version Control

[Bexley Hall]

Hi Tom,

>> But, almost universally, "It only works for tracking source code".
>> (Most of my colleagues aren't *just* "programmers" but, rather,
>> system engineers/designers.  As such, writing code is a *tiny*
>> part of a project -- O(10-20%) -- and one of the *easiest* to
>> handle).
>>
>> Of course, what they mean is "it only works for tracking lines
>> of ASCII text".  I.e., even if it allows BLOBs to be checked in,
>> there are no effective tools for diff'ing two arbitrary BLOBs in a
>> way that "adds value" to the differences detected.  And, the idea
>> of being able to *merge* two arbitrary BLOBs is *beyond* BFM
>> in their minds...
>
> Well, the question is is there some way to find value between
> BLOB at rev5 and BLOB at rev4?  If there is, then yes, git's a fine VC as
> you can do the plumbing so that you pass rev4 and rev5 to whatever
> tool gives value.  But that's outside the scope of the VCS.  It just
> needs to handle the data.

Ah, I vehemently disagree!  A VCS that just lets me tag objects
with version numbers and then faithfully stores/retrieves them
is little more than a disk drive!

Inherent in the idea of "versions" is the concept of *change*.
If two things are identical, then there is no need to track
versionS!

This immediately begs the question:  what is the DIFFERENCE
between these two versions?  And, to present that difference
in a form that is meaningful to the entity posing the question!

If it just said "the Standard Library has changed", I suspect
you wouldn't be very happy with that level of detail!  (e.g.,
"The photo on page 27 of the manual is not the same as it
was in the previous version" is more useful than "The manual
is different than it was previously".  And, "Here are the
two images XOR'ed together so you can identify the nature of the
differences -- without having to do so manually")

>> This makes sense given that the FOSS folks *tend* to only be concerned
>> with writing code.  Not documenting it, testing it, maintaining it,
>> "selling" it, designing the devices on which it operates, their
>> manufacture, modification, etc.
>
> That's not true.

Then which CAD formats do they track?  How do they show the
differences between two versions of a fabrication drawing?
How do they show the differences between two versions of
a user manual?  The differences between two ROM images?  etc.
Even if you take the attitude that you need not support
file/object formats that originated in the non-FOSS world,
I don't see much chatter about their FOSS counterparts.

(compare two PNG's instead of JPEG's; two .sda instead of .cdr;
etc.)

[Again, this goes to my insistence that VCS are responsible
not just for preserving (object,version) tuples but, also,
for facilitating the review of their differences!]

>>> One way of looking at things
>>> frankly is that all VCs suck somewhere.
>>
>> Yes.  VC needs the equivalent of "Eclipse".  A structured environment
>> into which specific support modules can be "plugged in".  *And*,
>> a user base that isn't confined to one discipline (i.e, "writing
>> lines of ASCII text delimited by newlines").
>
> Right.  git is pretty handy here again ;)

So was CVS.  My "hybrid" VCS (built on a stock cvs release) lets
me do all these things.  But, has required a sh*tload of effort
on my part to get all the "extensions" in place.  And, relies
implicitly on me being consistent with how I do things.

E.g., I can checkin a changed AutoCAD drawing (.dwg) and later
query the VC system for the changes that I made *to* the drawing
and inspect them visually.  But, chances are, if *you* changed
that drawing the comparison would be too "noisey".

By relying on the "compare" functionality to reside within the
VCS (where *should* it reside?), I can easily identify very
subtle changes that have crept into a design intentionally or
unknowingly.  E.g., I once stumbled across a short that had
crept into a PCB layout just by comparing the two versions
and looking to see what was flashing.  I'd have never been
able to find it as quickly, otherwise.

>>> For me, you can pull bisect
>>> from my cold dead hands, and I'll go to some lengths (read the git to
>>> $VC hoops) to keep it usable.  But that's because it's a huge part of
>>> my debug workflow.
>>
>> With Perforce, you can annotate each line of a source listing
>> with the version at which it was introduced.  Like a "visual
>> bisect", in effect.  I.e., you can examine the surrounding
>> text and see when *those* changes were introduced (before/after?)
>> to get a better idea of how things fit together and where the
>> "break"/failure might originate.  (perhaps it wasn't the
>> specific revision/change that you sought but, rather, something
>> done after it that aggravated the problem)
>
> Yes, you can do all of that too with git (git blame) and I have vague
> recollection of doing this with subversion and CVS.  But bisect, for
> me and my work flow was a light bulb moment.

Of course!  Another case of "What's changed?" ("WHEN did it change")

>>> On the other hand, if you're talking about a project with a fixed set
>>> of N developers, group preference is probably the biggest factor.
>>
>> I think that is what it *always* boils down to, in the end.
>> Folks rarely "think ahead" to what someone else *might* want to
>> use, later.  Rather, they pick what they are comfortable with and
>> "force" others to adapt to its use.
>>
>> When was the last time you said, "Gee, this really should be done
>> in Prolog but I don't *know* prolog so I'll write it in C++
>> instead..."?
>
> Well, it depends on if there's really any downside to C++ instead in
> this case :)  Yes, I'm losing the forest for the trees with that
> example.

The point I  was making was that if it "REALLY should be done in
Prolog", that *implies* there is a downside to any other approach.
But, "you" are outweighing that downside by the corresponding
"downside" in the "implementor" ("I don't *know* Prolog...")

Engineering is always a search for the "least bad" solution.  :>

> Going back to your original requirements, git isn't centralized, so if
> that's a hard requirement, you're looking at subversion really.
> Otherwise, everything not named CVS meets your needs because the
> problem areas you first spelled out are the common drawbacks of CVS.

I've just found "management" of "things" tends to be much easier
when centralized.  E.g., I can manage a dozen diskless workstations
in with an order of magnitude less effort than I can manage
a couple of PC's!  Everything is in one place.  I don't have to
backup N different machines, hope that N different developers
are backing up their individual repositories, worry that 'Bob'
isn't aware that we're replaced foo.lib with bar.lib and the
API is entirely changed, etc.

(Ever watch an army of IT drones fanning out through an establishment
installing upgrades/configuration changes?  I find it tedious just
dealing with machines in five or six different *rooms*!)