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
[EMAIL PROTECTED] 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: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> Haefelinger, Wolfgang
> Sent: Friday, 2 February 2001 12:03 p.m.
> To: '[EMAIL PROTECTED]'
> 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:[EMAIL PROTECTED]]
> > Gesendet: Freitag, 2. Februar 2001 12:39
> > An: 'Haefelinger, Wolfgang'; [EMAIL PROTECTED]
> > 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: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED]]On Behalf Of
> > > Haefelinger, Wolfgang
> > > Sent: Friday, 2 February 2001 7:53 a.m.
> > > To: '[EMAIL PROTECTED]'
> > > 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: [EMAIL PROTECTED]
> > >
> > > _______________________________________________
> > > Info-cvs mailing list
> > > [EMAIL PROTECTED]
> > > http://mail.gnu.org/mailman/listinfo/info-cvs
> > >
> >
>
> _______________________________________________
> Info-cvs mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/info-cvs
>
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs