[Tfug] Version Control

[Bexley Hall]

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

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.

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

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

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

>>> all the mentioned platforms with success, although historically
>>> Mercurial has been better on Windows, and some people prefer it's
>>> command line.    Either of them will be orders of magnitude faster
>>> than CVS or Subversion for a larger project.   There are also tools to
>>> bring your existing repo's in, retaining their history.
>>
>> What do you consider a large project?  Do they handle independent
>> (though related) projects in the same repository?
>
> git submodules is how you do this, with git, and it has its fans and detractors.

Thanks, I'll see what I can find regarding its implementation and
its proponents/opponents