| I'm pretty much aware of semantic model of distributed version control. Problem is git introduces new concepts (useless outside of git) which are widely used with and without cause. Check out various short descriptions of push command: * git — "Update remote refs along with associated objects" * mercurial — "push changes to the specified destination" * bzr — "Update a mirror of this branch" * veracity — "Push committed changes to another repository instance" * fossil — "Push changes in the local repository over into a remote repository" As you may want to see, all of them except first one, are easily readable even by person used some VCS before. But not git — to understand what push command does, you have to have gitglossary opened in front of you. > All DVCS systems involve creating and editing a series of changes to a directory tree git is not — it stores only snapshots and changes are calculated every time you want to see them. > the revision history is a document that you're trying to edit. It is revision history, not "a document". To be precise, in DVCS it is directed (except darcs) acyclic graph, aka DAG of source code revisions. > Those concepts map directly to the HTML wire format, so in practice, you'll end up learning that One and only VCS (of 7 I have used) I've ended up learning guts was Git. > They're easier to use for beginners, but they're more fragile and their internal formats are more obscure. Which way are they fragile exactly? Could you please back this statement up with some examples? And why one should care about VCS internals unless he's VCS (plugin) developer? |