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.

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

  1. >That is, .cvsignore and friends are indeed added to the default list.

    Good, that’s how I implemented it.

  2. 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).

  3. 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.

  4. Ah, Eric, is CVS-fast-export really up to eleven hundred versions now, or do you perhaps have a comma in the first line where you meant to have a period?

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

  6. >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 cpnventions or whatever.

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>