[Tfug] Version Control

[Bexley Hall]

Hi Yan,

On 4/2/2013 2:17 PM, Yan wrote:
>> Can these files be R/O and still use the repository?  Or, are they
>> used to track the dynamic state of the repository?  I.e., could
>> you copy the hierarchy onto a read-only medium and still *use* it?
>> (with the ASSURANCE that the repository's integrity is physically
>> "uncompromisable"?)
>
> I've never tried this, personally. I would *guess* that if you had the repo
> on an r/o medium, you would be able to do stuff like look at the logs and
> diffs and so forth, but you wouldn't be able to commit files (even if the
> files themselves were r/w). That's just a guess, though.

Of course, you wouldn't expect to be able to check *in* changes,
import new files, etc.

But, you *should* be able to check *out* portions of the repository.
So, if any of these files littering the hierarchy hold the state
of checked out files/modules (i.e., if they are updated even when
the files residing in the repository are not!), then you can't
deploy an IMMUTABLE snapshot of the repository -- one where you
are 100.0000% sure that the repository's contents CAN NOT be
altered EVEN IF THE SOFTWARE, OS, HARDWARE, etc. fail.

I've been trying to address a similar in PostgreSQL (RDBMS). IMO,
it should be possible and *practical* to deploy an instance of
a database on read-only media if you are willing to prohibit
updates to the data *in* that DBMS (Hint:  you *can't* do this
in PostgreSQL as it treats "read only" as a *permission* that
the RDBMS extends to clients -- NOT an attribute of the media
with which *it* must also comply!)

[I'll add this to my test criteria to see how well each of these
candidates address that issue...]

> So, how do "other (non-git) tools" determine the state of the repository
>> and the files that it governs?  Or, is *all* of that information exposed
>> via formal git(1) interfaces (the output of which is *stable* enough
>> that I could parse it without worrying that the next version of git will
>> alter those reports in some way that would break my scripts)?
>
> Honestly, I don't really know the answer. I'd imagine that the tools go
> right into the internals at least sometimes. I was thinking more in the
> sense that the end-user making modifications (like the diffing issue)
> shouldn't be parsing the git metadata themselves.
>
>> Would you trust Linus to not change his mind regarding the VCS
>> *he* wants to embrace?  When you've got an army of UNPAID droids
>> doing your bidding, its pretty easy to rationalize your decisions.
>> OTOH, if he was CEO of Linus, Inc and was *paying* all those
>> developers, how keen would he be on porting their repository to
>> some other tool -- given that he'd have to justify to stockholders
>> the expense for doing same?
>
> While Linus wrote git, and the Linux kernel was the first high-profile
> project to use git, git has hit critical mass in its own right since then.
> Linus' hypothetical decision to leave git would hurt it, but I don't think
> it'd hurt it in a major way.

My comment addressed the impact that would likely have on *other*
projects currently using git.  "Linus has moved on to *got*!  Should
we adopt *that* as our newest *darling* VCS??"

> In either case, the appropriate analogous
> situation (to a Perforce buyout) would be a company buying out the git
> project itself which, as we've seen with Oracle OpenOffice and Oracle
> MySQL, open source projects tend to survive these things by forking away.

Regardless, Perforce (or any other "closed" VCS) can persist beyond
the life of the parent company.  You just don't see any more updates
(*from* the defunct parent company).  Many FOSS projects are also
in a "stagnant" state in terms of ongoing development -- that doesn't
prevent them from continuing to be used.

> But, that ties up a lot of hardware.
>
> At the risk of opening a can of worms: this is what VMs are for :-)