[Tfug] Version Control

John Gruenenfelder jetpackjohn at gmail.com
Wed Mar 27 19:11:37 MST 2013


Don,

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

I've been following this thread and, while it seems likely that you
didn't *mean* this, I think that what you have written would very
easily lead someone to think that you are indeed looking for either a
monolithic VCS or a VCS that comes stock with a great many data type
specific modules.  Indeed, it seemed to me that this was the sort of
product you have been arguing for.

Also, all of the VCS that you or anybody else has mentioned *do*
version everything you toss at them.  Clearly, most only meaningfully
track changes in text files (as you are well aware), but that doesn't
mean they don't track versions of binary files.

I think it is important to remember that UNIX-land has *long* had a
history of working with data that originates in text form.  A few
examples:

* graphs in Gnuplot are not generated (usually) interactively or
graphically but rather via simpler scripts

* LaTeX/TeX document output (PS or PDF) is generated from a text file.
 Similarly, there are many other document formats that work this way,
such as (X)HTML, DocBook (XML), and so on.

Even though the eventual output is binary, the source is not.  I have
written many documents in LaTeX along with a much longer manual using
DocBook.  Add to that webpages and other random bits.  I've stored all
of these in a VCS at one time or another and since the source is text
you don't need to go through any extra steps to have your VCS track
fine line-by-line changes.


My point is not that this is *the* way or how everybody should do
things, rather that UNIX has a long history of this and this history
might offer some explanation as to why many of these
binary-diff-versioning features are not present.  Maybe.  :)

> [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]

**Yes**  In the end this the only way to really answer your question.
I'm sure you have been able to rule out a number of products, but for
many of the requirements you have mentioned, a side-by-side test is
the only way to get a truly useful comparison.

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

Hmmm... good questions.  I suspect that you may be correct for an
average free-time FOSS developer.  Such a person likely does not have
sufficient need to bother working on something like this, especially
since whichever VCS they choose to use *will* keep track of different
versions of any binary files they toss in.  I suppose this is enough.

>From my own experience, in one of my slightly larger projects, I
dumped most everything in the VCS (which was using CVS originally,
then I switched it to Subversion).  Nearly all of it was text of one
form or another.  This included all of the source, of course, but also
the ChangeLog and README documents, the contents of the website, and
some binary resources.  The binary parts were some bitmap resources,
the website images, and a small number of pre-built binaries to make
things a bit easier for users.

Since the amount of binary data was so small, I didn't need to bother
with anything beyond text change tracking provided by the VCS.  It
also kept track of versions of the binary files and that was enough.
I mention this because I (and this project) likely fall into that
category of FOSS developers who are sufficiently served by the
available tools and therefore don't need to extend the tool to handle
other/newer binary file formats.


-- 
--John Gruenenfelder    Systems Manager, MKS Imaging Technology, LLC.
Try Weasel Reader for Palm OS  --  http://weaselreader.org
"This is the most fun I've had without being drenched in the blood
of my enemies!"
        --Sam of Sam & Max




More information about the tfug mailing list