[Tfug] Version Control

[Bexley Hall]

Hi John,

>>>> 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!
>
> Eric Raymond's 17 Unix Rules:
> Rule of Composition: Developers should write programs that can
> communicate easily with other programs. This rule aims to allow
> developers to break down projects into small, simple programs rather
> than overly complex monolithic programs.
>
> If you are looking for a monithilic VCS that internally knows about
> every imaginable file type ever created, or envisioned, I suggest that
> you seek suggestions from somewhere other than a Unix mailing group.

I didn't ask for a VCS that did all of those things.  But, I sure
as hell don't want a VCS that thinks everything other than "source
code written in USASCII" is not worth versioning!

> Microsoft might have a product for you.

I suspect someone with a *financial* motive may be more interested in
developing a product that addresses the needs of others BESIDES FOLKS
CONCERNED SOLELY WITH SOURCE CODE!

[Perforce has been recommended by several of my peers as the "least
bad" option given my constraints.  MS's "Team Foundation" has seen
nothing but admonitions against its use!  I'll build a perforce
server once I understand the best platform on which to host it.
Then, start checking in parts of my repository to see what working
in it is like, when it bogs down, how it handles crashes, etc.
For yucks, I may similarly check in the same portion of the repository
to git and svn -- on the same server and client.  Then, have *real*
data by which to compare their performance on "nontrivial" data sets]

+ Rule of Economy: Developers should value developer time over machine
time, because machine cycles as of the year 2013 are relatively
inexpensive compared to prices in the 1970s. This rule aims to reduce
development costs of projects

So, forcing me to invoke some *other* tool that *hopefully*
knows how to compare two <objects> and show their similarities
sure seems like a waste of developer time vs. machine cycles!
Do *I* have to (re-)develop that bit of automation?

+ Rule of Extensibility: Developers should design for the future by
making their protocols extensible, allowing for easy plugins without
modification to the program's architecture by other developers, noting
the version of the program, and more. This rule aims to extend the
lifespan and enhance the utility of the code the developer writes.

How many FOSS *programmers* are busy crafting extensions to
$Favorite_VCS that supports PDF objects?  DWG drawings?  MathCAD
notebooks?  PFM font definitions?  etc.?  (if so, where are they
all hiding their works??)  Making an extensible "product" is
pretty useless if the extensions don't exist!

+ Rule of Least Surprise: Developers should design programs that build
on top of the potentials users' expected knowledge; for example, ‘+’
should always mean addition in a calculator program. This rule aims to
encourage developers to build intuitive products that are easy to use.

So, a diff operator should provide "meaningful" output only on
certain types of objects??

Again, this just reinforces my point that FOSS software is written
by folks concerned with aspects of WRITING SOFTWARE and little more.
(alternatively, perhaps they lack skillsets in other disciplines?
how else do you explain the lack of support for other *popular* file
types??)