cvs question

I have this CVS repository, and at some point something happened to it so that now when I "cvs add" a new file to it, that file starts out at revision 2.1 instead of 1.1. I don't know what I did to make this repository think that everything should be major version 2, but I'd like it to stop. Anyone know where this is coming from or how to turn it off?

Update, 16-Mar-2005: Turns out CVS does this if any file in the current directory has a 2.x< revision. I "fixed" this by hand-editing all of the ,v files in cvsroot to have 1.x versions instead. It was scary, and somewhat tasteless as it retroactively changes history, but it seems to have worked.

Tags: , ,

26 Responses:

  1. omnifarious says:

    Switch to using Subversion? *big grin*

    That's actually not behavior I've ever seen in a CVS repository that wasn't cobbled together by stuffing RCS files into the right directories. Hmmm....

    • jwz says:

      It's entirely possible that someone fucked with the RCS files; the repository in question is the one my web site lives in, and that began its life inside Netscape, so people other than me mucked with it. (The whole site lived in the same CVS repository for many years, including personal pages.)

      But something made it sticky, and I can't figure out what...

      • waider says:

        I don't think stickiness (per CVS's notion of same) affects "add" commands, but in case it does you can try nuking the CVS/Tag file (if one exists)

  2. waider says:

    If it's happening to brand new files the first thing I'd check is $HOME/.cvsrc to see if there's a set of flags for "add" in there.

  3. unify says:

    I managed to do this too once. I think it happens if you do cvs ci -r2.0 or something like that. I never figured out how to undo it.

  4. zkzkz says:

    I think you need cvs up -A to clear any branch tags.

    But whenever CVS gets confused I just move aside my working directory and do a fresh checkout from the repository. I have a feeling some of your existing files are on this branch though. Better do a diff afterwards to see what changes in the fresh checkout.

  5. zkzkz says:

    From the manual

    When adding a new file, the second number will always be one and the first number will equal the highest first number of any file in that directory. For example, the current directory contains files whose highest numbered revisions are 1.7, 3.1, and 4.12, then an added file will be given the numeric revision 4.1.

  6. en_ki says:

    CVS revisions are meant to be opaque, but you can forcibly increment them if you want to. I doubt you can undo it without doing crazy shit like running Perl on your repository files.

    • me_not_you says:

      yes, cvs numbers are opaque, Use tags to convey meaningfull information.

      Basically another poster was correct, you have asked cvs to start all version numbers at 2.X, so it does. There's no good way for going back without a massage of the cvs repository( not necessarily a safe thing to be doing ). I wouldn't worry about it. It's just a number, remember to use tags at meaningfull points and it'll all work behind the scenes

  7. cyeh says:

    At some point, you must have invoked this command to the entire tree:

    Short of walking the tree and editing the RCS files to reset the version number, you're pretty much stuck.

    • jwz says:

      It wasn't me, it was one of those Netcenter shitheads, or whatever they were calling themselves at the time. My tree started off its life as a tarball of my part of the tree.

    • jwz says:

      There it is, dammit:

        date; author jonathan; state Exp;
        next 1.192;
  8. mark242 says:

    Like what was said before, you need to clear the major revision.

    1. Commit any files from your local copy that you'd like saved.
    2. Delete your local copy.
    3. Go into the cvs repository and do "find . -print -exec grep head {} \;" -- this will tell you the version number of every single file in the repository.
    4. For the files that are version 2.X, go in and manually edit those files to change the version to something else.
    5. Check out the repository.
    6. Do a test commit.

  9. transgress says:

    short of what everyone else said, could you not do something like checkout the last 1.x version, then diff them against the 2.x version, sed the files for the 2.x version switching it to 1.whatever, then import it as a new project, and then switch the two out?

    Seems like a lot of work, could just accept it as version 2 and call it progress.

    • jwz says:

      I don't even really care about the version numbers on the existing files, but I'd like to make it so that new files default to 1.1 without me having to do a little dance each time. It's slightly annoying when I'm writing a new perl script or something, that derives its publically-visible version number from CVS, and it starts off at version 2.

      It does appear to work if I do this every time I add a new file:

        cvs add foo
        cvs commit -m '' -r1.1 foo

      but I never remember to do that.

      • transgress says:

        you dont think having multiple files with different major numbers in cvs could cause some confusion? although I suppose I am assuming this is public cvs.

        as for the cvs commit, is that not something you could add to .cvsrc ? (my cvs-fu is lacking)

      • You're breaking a (BULLSHIT!) cardinal rule of CVS here: you're caring about the version numbers. It really does go better if you simply don't think about them.

      • violentbloom says:

        So can't you just copy the whole bundle somewhere else and start fresh and check them all in again in it's own tree. And then of course you'll want to change permissions so that other people can't touch that tree, and mess it up again.
        I've done that with perforce (which I really like by the way... and has a command line as well as the gui)

  10. hotabay says:

    As I think of the Mozilla repository ... I don't think they've ever hit 2.0. Would they be waiting for Moz 2.0 for that? I guess to do it you have to set that one little parameter somewhere.