[Tfug] Version Control

[Tom Rini]

On Tue, Mar 26, 2013 at 3:45 PM, Bexley Hall <bexley401 at yahoo.com> wrote:
> Hi Tom,
>
> On 3/26/2013 4:26 AM, Tom Rini wrote:
>
>>>> The obvious choices come down to Git and Mercurial.  I've used Git on
>>>
>>>
>>> There names have come up in correspondence with colleagues.
>>> Though none have given either a "wholehearted" endorsement.
>>>
>>> So, why "obvious"?  :>
>>
>>
>> Well, what were their complaints?
>
>
> I don't care to get involved in arguing *their* points of view
> on their behalf  :>  Similarly, I won't argue *yours* to them!  :>
>
> 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.

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

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

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

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

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.

--
Tom