> Version control is arguably confusing for beginners
NO IT IS NOT. <smack to back of head> That kind of thinking is broken.
Most people who have been around computers on Windows long enough eventually adopt it. They start creating zip files of directories and they put date codes on them. You laugh, but it works.
As such, it's really easy for me to explain Mercurial to them. I simply explain it that Mercurial holds those zip files with some extra information and a pretty GUI. It takes me 30 minutes, max, and they get it.
They have one branch. They occasionally share things with other people. And, very occasionally, they have to merge something--which generally gets resolved by taking this file or that file--but rarely actually merging content.
Things only start to go bad when you start adding concepts that require the user to keep state of the repository in their head. If the end user has to think about the DAG, yeah, THAT'S complicated. And that's broken.
I've now been using git and hg for so long that I know both. I now know enough about git that I have been able to unwedge my teams without just copying the repo (cue xkcd link: https://xkcd.com/1597/). I don't need to spend hours of Googling anymore, I just need quick reminders of "Oh, yeah, that stupid flag."
And, you know what, I have never, ever been in a situation where I thought "Gee, I really wish I was in git rather than Mercurial." The converse, however, happens at least once a week.
Perhaps one day my teams or my repos will be complicated enough that the light dawns. The fact that the *BSD guys still operate using CVS and Subversion makes me skeptical.
For me the problems are always merge conflicts. Don't know why, in SVN I wasn't afraid of merge conflicts, I just opened a GUI, clicked on some arrows, picked the parts I want and parts I don't want, save and done. In Git, even with gui tools, I often end up with a mess of .BASE, .LOCAL, .REMOTE files, then I can't merge it all properly, and even if I do it asks me to commit the changes again and it's a mess, so I just clone the repo again and copy the files (xkcd #1597).
If you think merging in svn is easier than git then you haven't seen the pathological cases of svn merges. The problem is svn has no concept of a repo root or branches, it only has directories, so sooner or later things get very very broken.
NO IT IS NOT. <smack to back of head> That kind of thinking is broken.
Most people who have been around computers on Windows long enough eventually adopt it. They start creating zip files of directories and they put date codes on them. You laugh, but it works.
As such, it's really easy for me to explain Mercurial to them. I simply explain it that Mercurial holds those zip files with some extra information and a pretty GUI. It takes me 30 minutes, max, and they get it.
They have one branch. They occasionally share things with other people. And, very occasionally, they have to merge something--which generally gets resolved by taking this file or that file--but rarely actually merging content.
Things only start to go bad when you start adding concepts that require the user to keep state of the repository in their head. If the end user has to think about the DAG, yeah, THAT'S complicated. And that's broken.
I've now been using git and hg for so long that I know both. I now know enough about git that I have been able to unwedge my teams without just copying the repo (cue xkcd link: https://xkcd.com/1597/). I don't need to spend hours of Googling anymore, I just need quick reminders of "Oh, yeah, that stupid flag."
And, you know what, I have never, ever been in a situation where I thought "Gee, I really wish I was in git rather than Mercurial." The converse, however, happens at least once a week.
Perhaps one day my teams or my repos will be complicated enough that the light dawns. The fact that the *BSD guys still operate using CVS and Subversion makes me skeptical.