revision control

Monday, November 13, 2000, at 09:24AM

By Eric Richardson

Instead of muddying up this page, click to read my new thoughts on revision control.

I still really like the idea of the CVS model for revision control. However, I'm having trouble figuring out a useful implementation strategy. Basically, my problem is twofold.

1) CVS is going to be a bear to work with in an environment which isn't based on files. Since all my processing would be in memory, having to write and read flat files adds another level of ugliness (and possible problems). For instance, to check in a copy of a document which has been edited by someone else since you checked it out (assuming the changes don't conflict), I would have to write the new text to a file, run a cvs update, then run a cvs commit.

2) CVS bases its conflict management on lines of text. This works great for source code, since it's comprised of a lot of short lines. However, newspaper articles are comprised of paragragh sized lines. Although... I guess you really don't want people to be able to make too many edits in the same paragraph.

Web based conflict merges could be interesting. Basically you would slurp in the updated text, with conflict connotation, display the conflicting paragraphs (along with revision notes, perhaps), and then go with whatever the person editing decides. There's always the chance they're going to blow away some legitimate changes, but that's pretty much a human-factor you can hopefully train out of being a problem.

All in all, I still like the thought of using CVS. I love the idea of seeing side-by-side diffs between article revisions, and being able to view revision logs (cvsweb for newspaper articles). Now it's just a matter of trying to figure out how in the world I can hope to think about implementing this.