How should cvs-fast-export be properly ignorant?

I just shipped version 1.10 of cvs-fast-export with a new feature: it now emits fast-import files that contain CVS’s default ignore patterns. This is a request for help from people who know CVS better than I do.

I’ve written before about the difference between literal and literary repository translations. When I write translation tools, one of my goals is for the experience of using the converted repository to as though the target system had been in use all along. Notably, if the target system has changesets, a dumb file-oriented conversion from CVS just isn’t good enough.

Another goal is for the transition to be seamless; that is, without actually looking for it, a developer browsing the history should not need to be aware of when the transition happened. This implies that the ignore patterns of the old repository should be emulated in the new one – no object files (for example) suddenly appearing under git status when they were invisible under CVS.

There is one subtle point I’m not sure of, though. and I would appreciate correction from anyone who knows CVS well enough to say. If you specify a .cvsignore, does it add to the default ignore patterns or replace them?

My current assumption in 1.10 is that it adds to them. If someone corrects me on this, I’ll remove a small anount of code and ship 1.11.

8 thoughts on “How should cvs-fast-export be properly ignorant?

  1. Note that there are (usually) three places where ignore rules can be stored in an SCM: in repository .*ignore file or equivalent per-repository/per-branch place, in local configuration for repository (clone or a working copy), global for all repositories (per-user or system-wide).

  2. That’s also the sane way for a program to behave. Conceptually, the order of processing options should be:
    0: Program built-in defaults (if any. May be in an external file not intended to be edited, because every time you update the app, it’s going to be overwritten)
    1: Global option file(s) (/etc/foo.conf, …)
    2: Per-user option file (~/.foorc, ~/.foo/foo.conf, …)
    3: Command-line-specified options (which may include some kind of -F option_file switch

    (At step 1, there might be more than one file; one at the “site” level, possibly in a directory that is part of an NFS filesystem and another at the “server” level, perhaps accomplished by some kind of “include” at the beginning of the server-level file by a competent site admin.)

    When different values for the same option (or mutually-incompatible options) are specified, the one processed last replaces any prior specification.

    That allows the maximum flexibility in where options are specified.

  3. BTW. does it support any ignore as target (.hgignore, svn:ignore, whatever Bazaar uses), or only .gitignore files?

    • >BTW. does it support any ignore as target (.hgignore, svn:ignore, whatever Bazaar uses), or only .gitignore files?

      Only .gitignores; there’s no need to be fancier than that, because reposurgeon is available to translate the resulting git import stream to use hg or bzr conventions or whatever.

  4. Yea, if you just “shipped version 1.10 of cvs-fast-export “….
    It sounds silly to then also say “people who know CVS better than I do” – like….at least appreciate the fact that considering you’re already in a small subset of humanity by having the luxury of knowing what a CSV is… that you already understand enough to see a problem in the world, even if ‘just’ a meeting-demand “problem”, you understand the transformative importance of improving (and not incidentally, PROMOTING) a very important {work|data|traffic} flow issue in the real world….and then you created an improvement and actually got it out to people who were in a position to most influence future events. As Homer Simpson said…”That’s it! I’m Going to Clown College!”

Leave a Reply

Your email address will not be published. Required fields are marked *