• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • cvs-plugin
    • None
    • Platform: All, OS: All

      If you use alias modules in CVS the CVS support in hudson will not work. I
      think this is an easy fix though--I'll suggest a couple of simple options below.

      Under these conditions:

      1. in CVSROOT/modules have an entry like

      WebApp -a components/app components/web

      (This is a module definition for 'WebApp' which is basically an alias for the
      two modules components/app and components/web. You can use it anywhere you
      would normally list those modules separately. It's a common mechanism for
      assemblies.)

      2. Update mode set to true or false--doesn't matter.

      3. Legacy mode set to true (so that 'components' path element appears and is not
      truncated just because it's got no repository files in it directly)

      The code gets checked out okay but hudson falls over calculating changes because
      it does a cvs log on "WebApp" but that's never going to work because there is no
      directory called WebApp. So here's the error in the console:

      $ computing changelog
      cvs log: cannot open CVS/Entries for reading: No such file or directory
      cvs [log aborted]: no repository

      ERROR: cvs exited with error code 1
      Command line was [Executing 'cvs' with arguments:
      '-d:pserver:anonymous@oliver:/usr/local/repository/maintree'
      'log'
      '-d'
      '>=2007-04-04'
      'WebApp'

      This is related to another problem: If I use an alias module then I have to use
      legacy mode or I'll get a rather strange error because there's a mismatch
      between the module I'm checking out and the directory I'm creating. The error
      looks like this:

      cvs checkout: existing repository /usr/local/repository/maintree/components/app
      does not match /usr/local/repository/maintree/components/web
      cvs checkout: ignoring module componets/web

      It turns out both problems go away if I change the checkout of the code to use
      the -N option, like this:

      cvs co -Nd WebApp WebApp

      This forces directory WebApp to get created with one subdirectory, components.

      Now when you do the log on the 'WebApp' directory it will succeed.

      Other options:

      a) Since -N means don't shorten the path, maybe you don't want to change that
      behavior. So instead you could change the 'legacy' mode so that it uses -Nd
      instead of completely omitting -d. You get the full path checked out, but you
      also get a new directory component 'WebApp'. It may not be ideal but I suspect
      it's pretty much what you are trying to accomplish anyway...?

      b) Keep checkout and legacy mode as they are, but change your log command. You
      will get the same result whether or not you specify the cvs module in the log
      command. I did an experiment. If you omit the module from the log command, it
      runs on the code you have checked out anyway, and nothing more. So it's the
      same result, but in the case where the module is WebApp and there is no WebApp
      directory, it will still work (apparently).

          [JENKINS-427] Cannot check out alias modules from CVS

          bkayser created issue -

          bkayser added a comment -

          Clarified the subject based on the conclusion just to change the label.

          bkayser added a comment - Clarified the subject based on the conclusion just to change the label.

          bkayser added a comment -

          I accidentally changed the summary on the wrong bug.

          bkayser added a comment - I accidentally changed the summary on the wrong bug.

              • Issue 337 has been marked as a duplicate of this issue. ***

          Kohsuke Kawaguchi added a comment - Issue 337 has been marked as a duplicate of this issue. ***
          Kohsuke Kawaguchi made changes -
          Link New: This issue is duplicated by JENKINS-337 [ JENKINS-337 ]

          bkayser added a comment -

          There's been no resolution to this. I would recommend implementing option (b)
          below. It's a small change.

          bkayser added a comment - There's been no resolution to this. I would recommend implementing option (b) below. It's a small change.

          akshay_abd added a comment -

          I've experienced this problem too .
          Voting for this issue .

          akshay_abd added a comment - I've experienced this problem too . Voting for this issue .

          akshay_abd added a comment -

          After trying changes to the source code and playing around its becoming clear
          that this is not a trivial fix =/. Even if the changelog can be computed, its
          difficult to determine if a cvs update can be done, so it falls back to blowing
          away the workspace.

          On top of that even if I comment out the deleting of the workspace the changelog
          is still not computed for some reason.

          On the plus side I've learned a lot about CVS alias modules, how convenient they
          can be to use, but how painful to work with.

          akshay_abd added a comment - After trying changes to the source code and playing around its becoming clear that this is not a trivial fix =/. Even if the changelog can be computed, its difficult to determine if a cvs update can be done, so it falls back to blowing away the workspace. On top of that even if I comment out the deleting of the workspace the changelog is still not computed for some reason. On the plus side I've learned a lot about CVS alias modules, how convenient they can be to use, but how painful to work with.

          Thanks for trying.

          I think the crux of the issue is that we can't figure out what modules are
          aliased to what, because with aliasing, what Hudson gave to CVS and what CVS
          checks out has no corelation, as far as Hudson can tell.

          I know there are some Java libraries out there that speaks CVS protocol — does
          it tell us how aliases are expanded?

          Or what if we check out /CVSROOT/modules and infer information from there?

          Kohsuke Kawaguchi added a comment - Thanks for trying. I think the crux of the issue is that we can't figure out what modules are aliased to what, because with aliasing, what Hudson gave to CVS and what CVS checks out has no corelation, as far as Hudson can tell. I know there are some Java libraries out there that speaks CVS protocol — does it tell us how aliases are expanded? Or what if we check out /CVSROOT/modules and infer information from there?

          akshay_abd added a comment -

          Yeah I was thinking along the same lines - seeing if we can get the info from
          CVSROOT/modules. I saw the format and got lazy - I really dont want to parse it
          and all - thats kinda overkill - the amount of work to do. Also its not that
          simple - theres a lot more logic involved even after the parsing since you can
          have rules for getting flat directories - and that definition can keep changing.

          But I didnt think about searching for a Java lib that already implements that
          ! I'll hunt around - if it can at least get module definitions thats a lot.

          akshay_abd added a comment - Yeah I was thinking along the same lines - seeing if we can get the info from CVSROOT/modules. I saw the format and got lazy - I really dont want to parse it and all - thats kinda overkill - the amount of work to do. Also its not that simple - theres a lot more logic involved even after the parsing since you can have rules for getting flat directories - and that definition can keep changing. But I didnt think about searching for a Java lib that already implements that ! I'll hunt around - if it can at least get module definitions thats a lot.

            manmohan manmohan negi
            bkayser bkayser
            Votes:
            5 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: