[Tfug] Version Control

[Bexley Hall]

Hi Zack,

>> Though none have given either a "wholehearted" endorsement.
>
> I'll wholeheartedly endorse Git, for managing just about anything.  I
> keep my multi-gig document repo in it, etc.

But are these all "text" objects?  If not, how is the diff between
two versions presented to you?

E.g., my gesture recognizer defines gestures in a manner that
allows me to render them graphically.  This is one of the
ways they are presented ("shown") to the user (so he knows
how to issue them).  The *models* from which these representations
derive are text.  But, examining them with your eyes wouldn't
give you any idea as to what the gesture really "looked like"
(sort of like examining a spectrogram and trying to figure out
what it "sounds like").

When I make a change to a gesture's definition, I want to compare
the *graphic* renderings of the gesture because that's what the
user "experiences".  Showing me that a "L34" was changed to "C22"
means absolutely nothing!

>> So, why "obvious"?  :>
>
> "well engineered and not going to go away" :)
>
> Lots of people working  on the code, and large companies relying on it
> - heck, Apple and Microsoft both support it in their dev tools.
>
>> What do you consider a large project?  Do they handle independent
>> (though related) projects in the same repository?
>
> As Tom mentioned, you can do this with git submodules, but be careful
> with these as they can be a bit hairy to work with.
>
>> Silly example:
>> - C standard library can be considered a "project"
>> - each app that *uses* the library could be considered separate projects
>> - the documentation for each of those apps are each separate projects
>>    from the apps themselves
>>
>> I.e., these things are independent but still interelated.  E.g., a
>> change in the app can necessitate a change in the documentation...
>
> I'd probably do multiple repos, one for each separate project, but
> lump the docs in with the main project.

But what about when they are evolving concurrently!  Replace "C standard
library" with "project-specific support library" and reconsider.

I.e., one "aspect" of the project could involve that library
and a particular app.  Another aspect could require that same
library and a *different* app.

E.g., my gesture recognizer went through the same sort of situation.
*It* is a free-standing project by itself.  Yet, when I was developing
the TV application, it relied on the gesture recognizer so there
was another "project" that was gesture recognizer plus TV app that
*uses* it.  This allowed me to introduce new mechanisms to the
gesture recognizer that were consequential to the TV application.
I.e., not representable in the original implementation.

Similarly, *those* changes to the gesture recognizer have to
be reconciled with other "aspects" of the project that also rely on
the (now modified) gesture recognizer.

If you have to slice a big project into lots of DISJOINT "projects",
it gets tedious maintaining them and ensuring that commits and
commitlogs reflect the actual reasons behind the design's evolution.
I.e., added support for multi-component gestures" (because the TV
app required them!)

> Unlike CVS and subversion, making different tags and branches and
> merging them is downright pleasurable in Git.
>
>>> Handling large binary files requires something like 2-4x object size
>>
>> "2-4x" the *original* object size?  Why, do they uuencode it before
>> processing it?
>
> 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".