@Eldelshell said:
VCS are for code.
Why? Do files other than code not have versions that need to be controlled? Could have fooled me.
@Eldelshell said:
Until every remote operation takes 10 minutes of downloading/uploading/comparing stuff.
You might want to upgrade from your 2800 baud modem.
Seriously, we don't have these problem. Sure, we have some things stored outside of VCS. But like I said above, binary != big.
@Buddy said:
What would be a good choice?
I don't know. I've seen something called git-annex. I think it's sort of you have some external collection of files, then pointers to those files where the pointers are versioned. I could be totally misremembering, or misrepresenting what it does.
@TheCPUWizard said:
It is a subset of my normal comparison of CVCS vs. DVCS (regardless of actual tool). If you get benefit from having a central point (which typically implies having reliable connectivity) then go with a CVCS. I find this to be "the truth" for most business/corporate environments.
My attitude is as follows. Even for business/corporate environments, disconnected operations can be quite beneficial for people who travel and want to work from planes, airports, trains, etc.where there is either
no internet or only expensive internet. But even beyond that, at least compared to Subversion, I think that Git and Hg offer a bunch of useful advantages that are mostly or entirely incidental to the fact they're distributed;
git add --interactive
I think is amazing, as is the ability to amend and rebase commits that haven't hit a public branch. You could write some wrapper commands around Subversion to do all this (and I actually
have written a script that acts as a limited, kinda crappy version of
git add --patch; git commit
), but by the time you put in that effort, why not just use Git?
@boomzilla said:
How do you know [you could add locking without changing 95% of the code base]? I seriously doubt this.
I've already explained how you could get a useful locking implementation in Git that is reasonably consistent with its overall operation
1 [
1,
2, last part of
3]. I am nearly positive you could implement the locking portion entirely on top of the existing git commands (you could actually even do it as add-on scripts and hook up a [i]git lock[/i] command in the config file); the only thing that would have to
change is the part that pulls a blob from the repository and puts it into the working copy: you'd want to have that check whether it should mark it read only.
(Though I again reiterate that I'm not convinced an external system would be worse.)
1 Well, with the caveat that it would only work well with a "push" model where people have commit rights, and not for a pull-request or patch-based thing where human intervention is needed for commits to happen at a "definitive" repository. But that's still a lot of Git users.