RE: problem with "co -d xx -n" : bug or feature?

[Haefelinger, Wolfgang]

Hello,
'down-nailed'  my problem (see below) to next few lines
in  file  ~/src/modules.c (around line 533). I included 
the #ifdef and #endif lines - and voila, cvs behaves as
expected.

#ifdef HAVE_MAJOR_HACK
      /* XXX - XXX - MAJOR HACK - DO NOT SHIP - this needs to
         be !pipeout, but we don't know that here yet */
      if (!run_module_prog)
         goto do_special;
#endif
      dir = where ? where : (mwhere ? mwhere : mname);
      /* XXX - think about making null repositories at each dir here
         instead of just at the bottom */
      make_directories (dir);
      if ( CVS_CHDIR (dir) < 0)
      {
         error (0, errno, "cannot chdir to %s", dir);
         spec_opt = NULL;
         err++;
         goto do_special;
      }

Two questions remain:
(a) after all, what does  the  above 'XXX - XXX' comment
    mean and where will cvs fail now?
(b) my naive assumption about an  (ampersand) module was, 
    that a module is something  like an abbreviation for
    a (possible)  large  list  of  arguments to cvs, e.g. 
    writing the ampersand module
      am &mod1 &mod 
    and executing 
      $cvs co am
    is exactly equivalent with
      $ cvs co mod1 mod2
    or, in  other word, my assumption was that an argument
    identified as 'module' gets expanded by its definition
    but the result of this  expansion is evaluated then as 
    if I had typed it manually on the commandline.
    But this is  not the case: my assumption is that there
    are two evaluation procedures, one for modules and one
    for 'files' and my question is just: why?
    
Bye,
Wolfi.

> -----Ursprüngliche Nachricht-----
> Von: Chris Cameron [mailto:address@hidden
> Gesendet: Freitag, 2. Februar 2001 12:39
> An: 'Haefelinger, Wolfgang'; address@hidden
> Betreff: RE: problem with "co -d xx -n" : bug or feature?
> 
> 
> There used to be a patch available at cvshome to fix a 
> similar problem in
> the modules file.  I cannot remember the exact details, but 
> we installed the
> patch.  AFAIK it has not been incorporated into the main CVS 
> tree.  Sorry I
> can't give you any more details, but I'm out of the office, 
> visiting sales
> offices in the Americas, so can't get at our CVS repository 
> to give you more
> details.
> 
> > -----Original Message-----
> > From: address@hidden
> > [mailto:address@hidden Behalf Of
> > Haefelinger, Wolfgang
> > Sent: Friday, 2 February 2001 7:53 a.m.
> > To: 'address@hidden'
> > Subject: problem with "co -d xx -n" : bug or feature?
> >
> >
> > Hello there,
> > here's  my  problem:  defined an "ampersand module"
> > in  $CVSROOT/CVSROOT/modules and got a problem when
> > checking out the module using checkout options "-d"
> > and "-d" and want to know whether this is a (known)
> > bug or a feature. That's what I have and what I did
> > on
> >  $uname -a
> >  SunOS intra-dev 5.6 Generic_105181-05 sun4u sparc SUNW,Ultra-2
> >
> >  $cvs --v
> >  Concurrent Versions System (CVS) 1.10.7 (client/server)
> >
> > My repository contains the directories "mod1" and "mod2".
> > Want to checkout them both with a symbolic name. There-
> > fore I added the line "am &mod1 mod2" to the modules
> > file:
> >
> >  $ cat $CVSROOT/CVSROOT/modules
> >  am &mod1 &mod2
> >
> > That's pretty fine since
> >  $ rm -rf am
> >  $ cvs co am
> >  $ ls am
> >  mod1 mod2
> >
> > does exactly what I want. Even better,
> >
> >  $ rm -rf xx
> >  $ cvs co -d xx am
> >  $ ls xx
> >  mod1 mod2
> >
> > let's me checkout the modules in another directory. That's
> > wonderful, wow!
> >
> > BUT, trying also option -n to prevent any additional checkout
> > script from beeing triggered behaves unexpected:
> >
> >  $ rm -rf *
> >  $ cvs co -n -d xx am
> >  $ ls
> >  mod1 mod2
> >
> > The modules are checked out in the working directory and not
> > as beeing told in the subdirectory "xx".
> >
> > BUT-BUT, on the other side,
> >
> >  $ rm -rf *
> >  $ cvs co -n -d xx mod1 mod2
> >  $ ls
> >  xx
> >
> > does the right thing.
> >
> > Ok, I'm much too stupid to understand why 'cvs' behave in
> > this way, therefore  I  ask you, what's going on here. If
> > this is a bug, I'm willing to fix it.
> >
> > Thanks,
> > Wolfi.
> >
> >  _Wolfgang Haefelinger________________________
> >  voice: 069-263-16582
> >  email: address@hidden
> >
> > _______________________________________________
> > Info-cvs mailing list
> > address@hidden
> > http://mail.gnu.org/mailman/listinfo/info-cvs
> >
>