tortoiseCVS and FM files

[Andrew Warren]

Sandy Harris wrote:

> > CVS is designed for line-based computer source code and NOTHING
> > ELSE; it doesn't work for freeform human-language text,
> 
> Sure it does. I've used CVS with a large collection of HTML files.
> It worked just fine.

    If you define "work" narrowly enough, then yeah, it'll work...
    It'll store your files, let you retrieve them, and not catch
    fire.

    It won't accurately merge and diff, though, so you won't be
    able to use branches or allow multiple authors to work on the
    same files simultaneously.

    Worse, if you TRY to merge two branches, it may appear to
    perform the merge without error or conflict, but it won't have.
    This sort of silent failure is a disaster, especially since it's
    not always clear to CVS novices that certain CVS operations even
    INVOLVE merging.

> The big advantage was that because my docs and some doc-related
> scripts and makefiles were all in CVS, it was relatively easy to
> build docs as part of the release process.

    Yeah, I agree; it's nice to have everything in one place.

    I'd argue, though, that there are better tools than CVS for
    archiving your docs and build files.

> This should work fine with Frame if you store your files in XML
> or even MIF.

    No, unfortunately it's not even close.  Try this:

    1. Save a Frame document in MIF format as test1.mif.
    2. Move a couple of paragraphs or a figure or something.
    3. Save the modified document in MIF format as test2.mif.
    3. Compare the two files using your favorite diff program.
    4. Gaze in astonishment at the thousands of differences.

    XML's no better; comparison of XML files REQUIRES a diff
    program that's aware of XML structures.  Line-based diff, as
    used by CVS, simply doesn't work.

    If you MUST use CVS, you need to tell CVS to treat Frame files
    -- fm, xml, or mif -- as binaries, so it'll never try to diff
    or merge them.  If there's more than one person who might want
    to edit the files, you'll also need to enforce file-locking
    somehow, so there's no chance that two people will be
    simultaneously working on the same file.

> Subversion was designed for version control of web sites and is
> intended to handle versioning of binary files better. It might
> be worth a look if you use a lot of graphics in your docs.

    SVN's more efficient with binaries, but it still doesn't do
    diffs and merges on them.  Everything above applies equally
    to SVN and CVS.

    -Andrew