[Tfug] Version Control

[Tom Rini]

On Tue, Mar 26, 2013 at 7:37 PM, Bexley Hall <bexley401 at yahoo.com> wrote:
> 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!

And all of the metadata associated with each change (don't forget,
once you get outside of CVS everything does a "change set" these
days), and in theory you get useful information with the change.

> 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.

As someone else said, that's what difftool is for.  How do you
compare, exactly, two CAD files? Or jpegs?  Or ROM images?  You take
the tool that knows said format and can do something useful.  This is
your plugin architecture you've talked about in other posts.

[snip]
> 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.

I agree, with the caveat that it's up to AutoCAD to provide a
documented well enough file format so that someone can usefully
compare two drawings and do something useful.  I imagine for file
formats where this is possible, and folks care enough, there's a tool
you can hook up with difftool and get what you want (I'm only
tangentially associated with a bunch of OSHW folks, I don't know if
EAGLE/alternatives have such tooling today).

This is partly why I would swear some file formats essentially do this
in-app as they're the only thing with a chance of really understanding
and displaying what changed from A to B.

>
>>>> 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.

Right, development silos suck, but existed before DVCS and will
probably (sadly) exist long after either of us stop coding :)
So-and-so kept their work on a tmpfs directly on their not-on-a-UPS
system and we had a power blip last night and now they lost a month of
work isn't a DVCS problem :)

--
Tom