2 ms·

Wikipedia has branching now in the form of "approved revisions", and it has a lot of long standing TODOs like annotate that would be solved by a SCM. The stora

• philwelch 16y ago
  Are approved revisions really a branch or just a tag somewhere in a linear version history? With branches you can have n parallel branches, whereas with Wikipedia it seems--though I may be wrong--that you just have one version history, with one or more revisions within that history flagged as "approved". (Having n branches of a Wikipedia article would be frowned upon, since the community decided in the early days that you can't fork an article--that only gets in the way of building an authoritative and neutral version--though it has been argued in the past that having multiple forks on controversial topics, each written from a particular point of view, would be more informative.) Also, Git-style branches only make sense as alternative branches of the entire repository, which doesn't exist in Wikipedia terms because you can't atomically commit changes to multiple articles together. It's more than possible to have a wiki with branching and cross-page atomic commits--it's even a good idea. But it wouldn't fit Wikipedia. And to get around the atomic commit problem (given the massively concurrent editing that happens on Wikipedia) you'd have to essentially have one Git repository per article, at which point you're probably better off with a different type of backend.
  • avar 16y ago
    > Are approved revisions really a branch or just a tag somewhere in a linear version history? A Git branch is just a different head, but no, those things don't have divergent histories. They're just moving tags. Anyway, semantics aside I meant that they're doing things now that maps effortlessly to a scm. > Having n branches of a Wikipedia article would be frowned upon Not if it was well supported. Saying "hey, I modified the article in my own private branch, check it out and merge it if you want" would beat a long argument on a talk page any day. Branch support doesn't need to entail multiple publicly accessible (as in the stuff normal readers see) versions of articles. > Also, Git-style branches only make sense as alternative branches of the entire repository What? No, they'd also make sense even if there was one Git repository per page. > you'd have to essentially have one Git repository per article, at > which point you're probably better off with a different type of > backend. We won't know until we try, will we? But there are lots of advantages to using a well understood and simple data format with multiple implementations over a custom schema, but of course a custom format has its own advantages.