[Tfug] Version Control

[Bexley Hall]

Hi Tom,

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

Yes.  But I maintain the metadata should reside in a formal
database -- so other tools can access it directly (without
having to write a custom script to extract that data from
files scattered through the hierarchy).

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

But this can't be done without the VCS's involvement.  I.e., it has
to pass metadata regarding the *type* of object(s) that are being
compared -- not just a "name" (since I contend that names shouldn't
be relied upon to indicate the type of the object).

Otherwise, you have to know what the types of the files are
when you invoke diff (or difftool).  *Or*, rely on that tool
to accurately determine the type(s) involved.

OTOH, if the user can *specify* the types of the files when they
are added/imported/checkedin/etc. to the repository, then all
the VCS has to do is remember this and pass it as an argument
(or, a pair of arguments) to any tools that it invokes (to
diff, merge, print, etc.)

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

They do (at least the DWG format is well documented).

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

One (?) would assume this was already in place for the ubiquitous
formats:  JPG, PNG, GIF, TXT, etc.  One would also (??) assume
the prominent FOSS file formats would similarly be supported.

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

You can cheat.  :>  (Obviously, I haven't expended a boatload
of time writing custom "comparators" and "renderers"... I've
got more important things to do with my time!  :> )

For example, I compare schematics by "print to file" (as a graphic)
and then display the XOR of the two *graphic* renderings.  This
is an inexpensive solution (code it in a few hours) and gives you
most of what you need:  "Look over here!  There is something
changed!!"  (though no idea what those changes *mean*!)

However, it requires consistency on the object maintainer's part.
E.g., If I randomly move stuff around the "page" (for no good
reason), the XOR of the images will appear to show *lots* of
"differences" -- even though there are none of any *consequence*
(e.g., maybe I moved everything over a little bit so it was more
"centered" on the page).

[Of course, doing this doesn't *break* anything.  But, it means
I have to review a lot of stuff that I really shouldn't have to
be bothered with.]

The same sort of thing can be done to "compare" a GIF to a BMP
to a JPG, etc.  (i.e., vastly different file formats but if the
essence of the file is its visual presentation, then those
differences are what you want to be "noticing"...

>>> 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 :)

I don't try to *force* folks to behave in certain ways.
OTOH, I *do* try to make things a lot *easier* for them to
do things "my way".

E.g., you can define a gesture model for my recognizer in
many ways *other* than the approach I have used.  But, then
*you* have to figure out how to show it to the user;  how
to *describe* it to the user; how to drive the recognizer
engine with *your* representation; how to ensure the gesture
is "distinguishable" from other existing gestures; etc.  I.e.,
its just *so* much easier to do things in a way that fits with
the framework I've already put in place...

[I exploit peoples' laziness  :>  Make it hard for them to
misbehave!]