> I don't think anyone wants to go back to the bear skins and stone knives of centralized version control they can't effectively use from a modern system.
When working on a small team with everyone in the same office, there was nothing wrong with cvs, rcs, SourceSafe, Subversion, etc.
From my perspective SVN merges were absolute ape show even with as small as 5 people in the team.
Internet down - cannot do anything because you cannot even commit stuff with subversion. Let alone some totally obscure version control software I was working with as well.
Yes it was better than making copies of source code with date/time.
What is my killer feature for GIT: that I can work on my local repo and I can do whatever I want there. Only when I have to share the code I have to cleanup commits/code.
In general I probably could do the local repo with SVN and moving changes between them would be more hassle than worth probably. Also as young dev I did not thought about that until I saw workflows in GIT and it blew my mind.
> Internet down - cannot do anything because you cannot even commit stuff with subversion.
That, in itself, I consider a poor argument. The obvious solution would be to ensure Internet does not go down.
However, as an important design precondition, it forces the builder of such a system to embrace asynchronous, eventual consistency etc. Which leads to a much better design, even if your internet is 99.9999% available.
I'm convinced the "offline" requirements are the reason merging, rebasing, etc are so well done in Git.
No, my argument is that "ensureing connectivity" is a much simpler, cheaper and easier solution than "build all tools so they can handle offline".
Or: fine: git can be down. Now, how to read the framwork/api/lib documentation. Need to ask a colleague where that key for the CI was again: "build offlinefirst messaging". Need that backtrace from the CI the last time it ran "build some auto-asset-synching with the CI to local" and so on.
If you think that is a valid line of solving things, then something is wrong with the way you are solving problems.
No, my argument is that "ensureing connectivity" is a much simpler, cheaper and easier solution than "build all tools so they can handle offline".
The only problem with this is that ensuring connectivity is impossible. You can have multiple redundant backups with different technologies, and there's always a non-zero possibility that all of them will fail at once. This is compounded by factors like connectivity on the other end - how can you ensure connectivity when someone is working from a hotel for a conference, or from home, or from their yacht? Having a centralized repo means you also need people to work from their office if you're not going to control their connectivity too.
When it comes to source control, something that lets developers carry on working when they don't have access to a central repo is massively better than everything else.
Now, how to read the framwork/api/lib documentation.
It's in the repo, so ... just read it like normal because you have a local copy?
"Well done" might be overstating things... they're better than other tools alright, but if I only had a dollar for every single time I saw a poor git diff. Forget language-aware diffing; the line-level diffing doesn't even seem to handle even the dumbest cases of indentation and brace-matching with any intelligence when merging. They have a lot of low-hanging fruit for improvement.
When I needed to work with a subversion the last time, I always found myself using git and git-svn when interacting with the version control system.
It's not just the familiarity of the commands, but also the enormous flexibility you get in doing local operations to create and amend your commit history. And the speed of operations of course.
Yeah, i've worked with SVN projects both in office and in open source projects and i use it for a couple of my own projects where i have a lot of binary files (the common alternative to this with git is something like git-lfs but that is essentially sticking a cvcs into a dvcs while pretending you are only using the dvcs... and when it comes to dvcs i prefer fossil anyway) and i never really saw anything wrong with SVN. I might have been lucky, but that is a luck that goes back decades :-P
It's a classic case of a system designed for the largest scales being adopted by 2-person teams because it's "hip to be just like the big boys".
Git was intended for distributed development amongst literally tens of thousands if not hundreds of thousands of programmers.
Centralised SCMs worked just fine for typical dev teams of 2-15 people.
I've rarely seen a team that actually utilises even 10% of Git's features. Conversely, when they accidentally trip over the inherent complexity of a distributed SCM they always cause a giant mess and end up "fixing" it in bad ways.
Eh, Git works, which is all it has to do. The reason you see typical small dev teams use Git is because they're familiar enough with it from dealing with FOSS. And when you are doing FOSS, there's almost no contest – Git destroys the competition for n-person teams when n → ∞.
Besides, it's not even all that complex, there's just an abundance of bad information talking about "diffs" and "branches containing commits" and confusion over the word 'tracking', when most of that is either a convenient representation or an internal implementation detail that doesn't matter at all to the user.
OMG. This was one of my stumbling blocks in learning git. None of the explanations were helpful to me.
The other area that is a tremendous source of confusion is rebasing being described as "re-writing" history. There is no re-writing of anything in git during a re-base. There is some moving of labels (branches), which you might call "re-labeling" but all the commits that were there before a rebase are still there after in the git repository as well as a bunch of new commits.
The fact that all git operations are local (will except push, pull, fetch) and thus mistakes do not enter the (remote) repo so often, that’s really a great advantage.
- They are not "associative", as mathematicians say, which means that if a remote branch has two commits A, followed by B, merging A then B might give you a different result from merging just B. Stockholm syndrome has convinced many programmers that this isn't a problem, but it actually prevents the very sane reviewing process of reading individual proposed changes along a branch. In other words, this is one of the main reasons Git users have to follow "flows".
- Conflicts! 3-way merge treats conflicts as a failure to merge, and tools based on 3-way merge (Git, SVN, Mercurial, Fossil, CVS…) stop everything when a conflict happens. Now, remember that these tools are based on snapshots, and snapshots can never have conflicts. Therefore, conflict resolutions are forgotten, the only thing remembered is that "Commit [insert SHA1-hash] (Revision number [insert integer] in SVN) comes after these two parents".
This is so wrong that Git even has a command to "pseudo-fix" it, called `git rerere`.
Again, if this doesn't sound like a problem to you, this could be because Stockholm syndrome taught you that the tool gets upset if you merge from the same remote branch twice, or if you fork a branch that isn't called "master" and isn't on GitHub. In other words, because you're actually using a centralised version control tool ;-)
Few centralized source control systems ever adopted the "three-way merge" which is the big thing that makes git merges seem relatively magic in comparison. It was an evolutionary pressure thing: not implementing it in a centralized system was a local maxima, when centralized it is easy enough to constrain merges to easier to reason with "two-way merges", and implementing "three-way merges" was a lot of work for little gain (it didn't sell enough of the centralized tools you never heard of or no longer remember that did invest into it). Meanwhile when assuming merges are distributed and entirely offline-first decentralized source control systems had to invest into the "three-way merge" problem and at this point git has invested more than just about any other source control system this side of "academia" (and source control systems you don't hear much about these days like darcs/pijul).
git makes merges much easier through a lot of hard work on its part because it has to in order to survive. A lot of centralized systems were really bad at merges but we put up with it because it mostly worked and it was "good enough".
Svn does do three-way merges, see the section "External diff" in the svn book.
One thing I found in svn but couldn't find in git is merge tracking: you can merge individual commits and svn records which commits have been merged. The equivalent operation in git would be cherry-picking, and I believe git does not track metadata on cherry-picked commits.
Example: I have a branch A, and I've branched B off from A. B has extra commits x, y, z (in that order). I merge commit y into branch A. (In git, I would have to cherry-pick that commit.) Then I merge the whole branch into A. Now svn knows that y has already been merged, so it only tries x and z. But git (AFAIK!) attempts to apply all three changes, and then detects based on the file content that change y was already present.
In svn, due to merge tracking, I can merge commit y into branch A and also make changes to the code in the process, and svn still knows to skip y on the final "full" merge.
git plumbing I believe can represent such merge DAGs (though possibly not with guaranteed semantics and in the category of "not well enough defined if you attempt it") but I don't think there's ever been a porcelain command in existence that can build/execute such merges. It's long been a complaint I have that cherry-pick is too rebase oriented. As someone who prefers "rebase never" approaches to git it irritates me that there isn't a non-rebase cherry-pick.
Probably going even further off topic, in general I find it irritating with git that there's so much vocal "the DAG is aesthetically displeasing when used as a DAG" support that it seems tough for git to realize the power of its own DAG and/or better encode things that should be encoded in the DAG such as partial merges (versus today just throwing away partial merge information in rebases and cherry-picks) just because it "looks ugly" when actually used as such. Aesthetics should be the last concern over beneficial behavior? Aesthetics can be bolted on with cleaner user interfaces but lost data is always lost data?
The DAG is labelled. Most labels are boringly "parent: commithash". In the raw plumbing you can build other labels, a "cherry-picks: commithash" or a "replaces: commithash" or all sorts of things. git log won't follow such edges today, but it doesn't need to, and a lot of the folks that don't like the DAG aesthetically might prefer that anyway, but the assumptions that "parent: commithash" are the "only" edges in the DAG aren't baked in as much as people assume. For instance, think about git notes, they can have some pretty exotic edges. Again, not many people use that power today and most of the git "porcelain" has no idea what to do with it, but the DAG as a raw data-structure absolutely supports it.
Very interesting. Thank you so much for teaching me. I guess it would be possible to create a git plugin that tracks such picked cherries and that provides changed merge and rebase commands. (The plugin would use the existing plumbing to provide new porcelain.)
My current team relies on manual tracking: if there is a bug that needs to be fixed on a release branch and on the main branch, then the developer is responsible for adding commits to both branches. (Whether that is by making the commit on one branch and cherry-picking it to another, or by just making the change twice, is up to each developer.). I'm glad that everyone is so detail-oriented; normally we don't forget. But better support for cherry-picking would be quite useful imho.
> (and source control systems you don't hear much about these days like darcs/pijul)
A bit unfair, Darcs is indeed less fashionable nowadays because of performance issues on very large instances (which few projects actually have), Pijul solves these problems but is still alpha. In other words, this lineage of version control is between two different tools.
It's been maybe 10 years since I last used SVN so I don't remember exactly, but it was related to moving commits between trunk and maintenance/feature branches and back. I managed to mess up whole repository few times. It might have been my own ignorance though, I was a fresh junior at the time.
On the other hand with git I had less issues related to merging, after playing for couple of hour it just all made more sense.
Git has become so ubiquitous that I'd find it weird if a recent project was using anything else.
Even if most devs don't know even 10% of it (I'm in this category and I don't care), same goes with my car: It can drive very fast but I limit its speed to something I can control.
The analogy is a bit weak but in general I see no problem not using something to it's full potential.
> It's a classic case of a system designed for the largest scales being adopted by 2-person teams because it's "hip to be just like the big boys".
People are still saying this? I remember hearing this around 2007 when I started to use git. It's completely wrong. How would I, as a single developer alone, even use CVS or SVN? Have my own server running locally? I tried that and it sucked. Maybe there's some other tool I could use instead, well now I have to learn two tools. Git is popular because it works at all scales.
I worked with SVN briefly as it was out of fashion by the time I entered the workforce, but one thing I remembered about SVN was that there was a lack of standardisation between the clients.
I created the project using tortoiseSVN and any time a team member tried to add to it using a different client than tortoiseSVN it'd corrupt the entire repository!
That doesn't sound right. Actual corruption of the repository can happen, but not by simply using another client than your team members.
May be you mean something more alike commiting non-standard line endings? That can easily happen in git too, e.g. when the .gitattributes is different between worktrees.
May have been the case, it was about a decade ago now!
Somehow tortoiseSVN solved those issues, perhaps they had some smarts to normalise the line endings?
In any event, I've never had a git repo become corrupted in such a way after many years of continuous usage, but SVN seemed to fall over in a light breeze.
One point to add to the XKCD - driving an automatic transmission car is "steering wheel, gas pedal, break".
Most people don't even realize that there are micro explosions there around 2k times per minute let alone rest of the magic that happens in a modern car.
No one reads car manual and probably no one uses most of options in their cars. But still it is such a useful tool that many cannot live without one just like nowadays devs cannot live without GIT.
So I think it is perfectly fine to use only couple commands and don't even think about distributed graph and then adjust/learn when you need to understand more.
While I agree with your main point, as someone who used SourceSafe in the past I strongly dispute the claim there was nothing wrong with it, relative to the others that you mention!
Honest question: such as what? Some enormous projects were written with CVS (concurrent version control) including, IIRC, Unix system V and some Jet Propulsion Lab projects
The same things that are wrong with them when working in a team. I want to do experiments in separate branches, sync them across my desktop and laptop, merge them painlessly, merge various bug fixes to those branches and go through history without having to go make a cup of coffee while I'm waiting. And most importantly, I don't want those things to be any more pain in the ass than they need to be - and they are more painful in CVS, Subversion and SourceSafe.
Of course complex software can be written without Git - I've been writing software since before Git existed. It can also be (and has been) written without, say, lexical scoping. But it's just harder.
Out of curiosity, the other day I wrote a script that goes through each git commit in a repository and calculates how many lines of code there are, so I can see how it changed over time. That'd be fun in SVN.
When working on a small team with everyone in the same office, there was nothing wrong with cvs, rcs, SourceSafe, Subversion, etc.