Reply to post: Re: Cloud based services

Re: Cloud based services

The problem is that although git can do all that -- you can ship updates by email I'm pretty sure (and not just the git format-patch thing but commits), so the connectivity requirements are tiny in theory -- people (a) really, really want the issue-tracking stuff (b) in practice treat git just the same way they treated subversion and CVS, with a central system which runs everything, and (c) want it to be free. And that central system, for many people, is GitHub, so when it goes away the same doom befalls them that befell them when google code went away and when sourceforge went away before that (I know it, sort of, came back). And there's almost no collective memory -- anything that happened more than a year or so ago is forgotten -- and so the wheel of reinvention turns forever.

Don't entirely agree here. Even with a master repo (which you may put on github or not, as you wish), git still behaves fundamentally differently to both CVS and Subversion in a number of ways.

CVS is the most obvious, there is little concept of repository-level state unless you tag or branch. So a changeset will involve different revision changes for different files. History is completely in your repository, so lose it and all you have is a copy of the code, lose connection to it and you can't commit or checkout different versions.

SVN is a bit better, with the concept of a revision for the state of the code. However branching is mixed up with the directory structure of your repository. I haven't used SVN for ages, but the merge tracking feature wasn't introduced till 2008, I guess inspired by git. Again, history on repo only.

Git, locally stored history, even if you don't use it. Branching and merging on a graph based model, tools that let you diff freely across branches, commits and history. Using it with a central or master repository model doesn't actually detract from this. You can still commit, branch, checkout with no connection. Lose the remote and you still have all history and can make a new master. A central repo becomes a useful point of coordination, but it's no longer an Achille's heel. Lose it and you lose the extra nice stuff that's tied to the web-service, but not the actual commit information you would for subversion or CVS.