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

[Chris Cameron]

Sorry, I'm on the road at the moment and can't check my e-mail often, or the
CVS repository at all!  What you're describing seems very similar to the
patch I downloaded from cvshome.org (or it's previous incarnation) a year or
two ago.  If you can wait 3 weeks, I can check our repository when I get
home.  Otherwise, someone else may be able to help.  As I said previously,
there is (was?) a patch at one time to fix a bug similar to this.


***************************************************************
Chris Cameron                    Open Telecommunications NZ Ltd
Product Manager                           IN Product Management
address@hidden                           P.O.Box 10-388
      +64 4 495 8403 (DDI)                          The Terrace
fax:  +64 4 495 8419                                 Wellington
cell: +64 21 650 680                                New Zealand
Life, don't talk to me about life ....(Marvin - HHGTTG)


> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden Behalf Of
> Haefelinger, Wolfgang
> Sent: Friday, 2 February 2001 12:03 p.m.
> To: 'address@hidden'
> Subject: RE: problem with "co -d xx -n" : bug or feature?
>
>
> 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
> > >
> >
>
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs
>