[Tfug] Version Control

[Bexley Hall]

Hi Yan,

On 3/26/2013 11:27 AM, Yan wrote:
> To throw in my two cents: we use git pretty much exclusively in the lab. We
> have people that have all their dotfiles in git, we have big projects in
> git, etc.

Again, what do you consider "big"?  If you're talking less than a
millions lines of code, we're comparing apples to crabapples...  :>
(not counting "other objects")

> I don't know if anyone's mentioned this, but git (among others as well, of
> course) is fully distributed. Once you clone the repository from your
> server, you will still have it (including all the commits and file history
> and so forth) even if your server explodes. Also, you can go offline,
> continue working, making commits, etc, and then push that to the main
> repostory. It's quite nice.

I understand.  Though colleagues I have spoken with claim this
to be a *drawback* -- individual developers tend to work in
isolation "too long" and then there is a "commit frenzy" where
folks are all trying to merge very different versions of the
*entire* repository at the same time -- just before a release.
I.e., because they can freely modify their copy of the *entire*
repository, they are more likely to make "little tweaks" to
interfaces, etc.  Of course, always *thinking* those tweaks
are innocuous... until someone else's code *uses* that
interface (expecting it to be in its untweaked state) and
finds things suddenly don't work.  Then, the blame hunt begins
(all while management is pushing to get something out the door).

["Testing?  Did someone mention testing??"]

Of course, the solution lies in *policy*.  And we know how much
we all enjoy "rules" that *seem* to be arbitrary (from our
personal perspective):  "Why do we have to merge our changes
weekly?  Why can't we do it monthly?  Or, at prerelease??  All
these merges are a real PITA for me..."

> It can support any file type (although if you're storing movies and crap,
> there might be performance overhead). Heck, the sparkleshare personal cloud
> storage stuff is based on it.

It's relatively easy to *store* "any file type".  A different
issue is being able to make *sense* of those stored images!
If all your VCS does is store/retrieve versions of objects
but provides no meaningful way of comparing them, then it
does little more than a disk drive does!

> There are GUIs for git. One such is gitk. I'm not sure if it's first-party
> or not (ie, written by the git team), but it seemed nice the one time I
> needed it.

My experience with bolt-on GUIs is they are half-baked.  Certain
features of the underlying tool aren't available.  Or, work
poorly.  Or, the underlying functionality is misunderstood by the
implementors, etc.  Hence the ideal being a GUI that is *part* of
the actual "product".

> I'd say that git is generally becoming the (most) standard SCM in the open
> source world. It's used by the Linux kernel (Linus wrote git), supported by
> sourceforge, and is the base of github and bitbucket. Not that popularity
> means everything, but it's something to consider.

And Windows is the most popular OS; VHS was the most popular tape
format, etc.  :-(  So, we know how little "popular" means as it
relates to quality and/or capability!  ;)

E.g., I use FrameMaker for my documentation.  Beats any FOSS
tool or "more popular" tool hands down in terms of capability,
reliability, etc.  But, if you start counting "seats", it
looks pretty bad!

My concern with most of the FOSS VC tools that I've surveyed is they
are heavily oriented towards "writing code".  I don't see talk of
using them to store OpenOffice documents, CAD files, sound files,
database snapshots, etc.

I.e., the folks *using* them are mostly interested in writing
and tracking changes to *source code* and little else.