Like most things in life, what you value tends to make one thing more
important than another when you consider any object. This is why programs
like editors; programming languages; and in this case, file revision
management software, gets such visceral responses from so many of us. And
like many programs and subsystems, as deficiencies become more
obvious/acute with a program, when and how they are addressed also play
into that value.
Thus, I think it comes back to *use case* for everyone. What am I
protecting with this subsystem and how does it affect me?
Frankly, the high order bit for me, is usually protection from my own
silliness (most important), how easy/natural it is to use/fit into my
workflow(next in importance); followed by accidental/on-purpose changes
happening by my friends/coworkers 'behind my back'(important); how merges
are handled when I'm in a group setting; and IF AND ONLY IF I'm using the
tool kit to protect IP for a 'product', how easy it is to support
'releases' past/current/in-development at the same time.
The truth is, when I'm leading product development, that last one moves up
a few places, although I know that if the 'fit' or ease of using the tool
is not nearly #1, some members of the team will not use said tool in the
planned and expected manner - so I think I will tend to value 'ease of use'
as the most important attribute for me.
Truth is SCCS and from what I know of BitKeeper, has always met my
criteria, certainly for simple programs and even for documents like papers
and books. As I said, its what I use day to day (thank you Marc and team).
While I learned the direct get/admin/delta/prs commands, calling them via
Eric's "sccs(ucb)" front-end 'fixed' the harder to use part of
things.
Frankly, I have aliases 'get' to be 'sccs get' and the like.
I was at Tektronix and like many when Tichey released RCS by itself, Eric's
sccs(ucb) command was not available to me, so it seemed simpler and I was
attracted to it. But I quickly went to UCB and was re-introduced to SCCS
using Eric's front-end and I found the difference was a nit. SCCS was
what we used, so that became my go-to and has been for a long time.
SCCS was our systems at Masscomp, Stellar and later DEC (although DEC for
OSF/1 switched to another system whose name I forget which came from OSF).
At LCC, we used what the customer used, so we got to see a lot of them ;-)
That said, when Thinking Machines released CVS-II (on top of RCS) it did
seem like the cvs merge management and production tags tended to be the
easier/a good thing. When we used that system for an HP project at LCC, I
will say, the Thinking Machine crew had fixed the two issues I had
struggles with SCCS**. I used cvs again for a few other projects
including two start-ups later.
Since that time, I have been given Mercurial, SVN, and git. I'll ignore the
first two as they seem to have fallen from grace. I personally, find git
extremely heavyweight and only deal with it because I have too thanks so
linux pushing it into so many FOSS projects. I can and do have to use it,
but my experience is that we fight the tool constantly and I wonder if we
are ahead or behind. The git system supposed to be great for merges and
so-called 'pull requests' and I can see if what you value is being able to
grab something from someone else - *i.e.* what Linus does daily (merge lots
of peoples 'suggestions') and it probably does make it easier for Linus.
But .... I can say in a product setting, I have observed it is messy to
keep track of specific versions of things that make up a 'product. For
instance, I would like to be able to query, get me all the sources that
make of the 'Intel Parallel Studio, Cluster Edition' (I don't think it
can
be done!!
At least at DEC, when we released Ultrix, we put a tag into the DB and keep
a DB around for every file we used for the build. There was a script that
could be run, that get do an 'sccs get' against every file and we could
rebuild everything (VAX or PMAX) and it even included some of the 'layered
products' that the OS team controlled.
So, my observation at Intel, is we have more people wasting backed time on
'maintaining our common pools' here than we ever did at DEC or at any of
start-ups. As a sr person, I must say hmmmmm
Anyway - that's my 2 cents.
** Although, I'll believe Larry when he says he fixed said SCCS
deficiencies in Bitkeeper. I will say after a quick examination of doc and
his emails, it does sound like he picked up some of the good ideas from
other systems, but I can not say I have tried it.