Mana Mana Versioning

From ManaMana: ManaMana would permit an arbitrary number of branch points, not for a page, but for the wiki as a whole. To do this we start with the WayBackMode of CvWiki but do the thing on SubVersion because CVS doesn't branch branches very well.

I think a more sophisticated system like DavidsAdvancedRevisionControlSystem with its TheoryOfPatches? is called for.

Perhaps. I haven't delved in Darcs. Can you describe how it would make a difference?

CVS/RCS use the normal diff/patch tools, that have a rather limited understanding of the text they are patching - namely one of changed lines with fixed context. Ignoring white space makes it better, but still too dumb in case of conflicts. If there are few changes, there are few chances for conflicts at all, which seems to be the usual case for your typical large C(++) application, that is slowly evolving and gets fixes here and there. But consider Wiki, where pages are heavily edited and refactored, especially in the case of EditWars or topical pages (exactly the cases ManaMana strives to improve). Here the dumb diff/patch will break down. I know this from merges in heavily edited Java-Code, where the IDE sorts member and renames dozens of locations at once and pretty printing is done often (with different tastes...). Here CVS breaks down and I am grateful for the syntax-aware Eclipse-merge tool, that is undisturbed by methods moved around and ignores white-space. The patch-calculus of darcs knows different types of patches, e.g. search/replace, move, insert, delete, and knows which commutes with which. So it doesn't see conflicts at all, where a change is unresolvable for diff/patch.

Most text has structure, especially text that is also source code for a computer program. Because text has structure, changes to text tend to reflect its structure. A revision control system will, therefore, behave better if the grain size that it manages corresponds to the grain size of the items being managed. CVS/RCS does not do this. An interesting metric - let's call it the "Stambaugh Ratio" - for a revision control system is the ratio of the number of bits/bytes that actually changed to the size of the overall changeset (the total information stored at each revision). I posit that an ideal version control system has a Stambaugh Ratio of 1. The Stambaugh Ratio for CVS/RCS, especially when applied to natural language text, is significantly less than that. The Stambaugh Ratio, by the way, is also a reasonable figure of merit for software development tools like Make and Ant - specifically, for a given build, the ratio of the size of number of bits or bytes that changed to the total number of bits or bytes in the build. -- TomStambaugh

I wasn't thinking of cvs/rcs for reasons previously mentioned. What about DarcsVsSubversion?

Could you, or someone who knows DavidsAdvancedRevisionControlSystem, do a quick contrast and compare with EnvyDeveloper? -- TomStambaugh