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
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
Easiest way to move a branch to the trunk
I have a project/repository which has a main branch (trunk) for stable, released versions and a development branch. The development branch was branched off of the main branch a while ago for development and has going along gangbusters. Now it is time to release. What is the easiest way to move the develoment branch onto the main branch so that what is on the main branch is completely replaced by the development branch. I realize of course I could use "cvs update -j" to move it all over but that is going to create a boatload of conflicts. I can deal with conflicts easily (and tediously) enough but I wonder why I should need to bother. It seems that I should be able to simply replace the contents of the main branch with the development branch in an easier way, no? All suggestions welcome, thanx. b. -- Brian J. Murrell ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
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.
-Ursprngliche 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
Re[2]: Concurrent VS...
NLY I think the problem any VC system is supposed to solve is to NLY prevent multiple people from editing the same file at the same NLY time. CVS does this. Instead, people edit different copies of the NLY same file at the same time. The first person to checkin succeeds. NLY CVS will prevent checkins by others and will display a message NLY saying that they'll have to perform a merge (via cvs update). Thanks for the information ... I've only dipped-into docs so far and had found nothing obvious before I got really heavily committed to the installation! I shall use the reserved approach I suspect, and improve our management so we have the faintest idea who's editing whose files! Cheers, James. NLY To: [EMAIL PROTECTED] NLY cc: (bcc: Noel L Yap) NLY Subject: "Concurrent" VS... NLY Requiring Version Control, I have installed CVS for evaluation. (I NLY have used SCCS in the past but systems are different here now.) NLY One of my principal reasons for using a VC system is to avoid the NLY version discrepancies that arise from two separate developers NLY inadvertently editing the same file at the same time. NLY Have I selected the wrong VC system? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re[2]: Concurrent VS...
JD Maybe... maybe not. JD File locking is not the only solution to this problem. JD http://www.cvshome.org/docs/manual/cvs_10.html#SEC95 Thanks for the manual reference ... I've only dipped-into docs so far and had found nothing obvious before I got really heavily committed to the installation! Reading the above section related has helped greatly. Cheers, James. -Original Message- Sent: Wednesday, January 31, 2001 3:08 AM To: CVS Info List Subject: "Concurrent" VS... Requiring Version Control, I have installed CVS for evaluation. (I have used SCCS in the past but systems are different here now.) One of my principal reasons for using a VC system is to avoid the version discrepancies that arise from two separate developers inadvertently editing the same file at the same time. Have I selected the wrong VC system? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Easiest way to move a branch to the trunk
Brian Murrel wrote: I have a project/repository which has a main branch (trunk) for stable, released versions and a development branch. The development branch was branched off of the main branch a while ago for development and has going along gangbusters. Now it is time to release. What is the easiest way to move the develoment branch onto the main branch so that what is on the main branch is completely replaced by the development branch. I realize of course I could use "cvs update -j" to move it all over but that is going to create a boatload of conflicts. I can deal with conflicts easily (and tediously) enough but I wonder why I should need to bother. It seems that I should be able to simply replace the contents of the main branch with the development branch in an easier way, no? All suggestions welcome, thanx. I know that this is shutting the barn door after the horses have gone but your new development should have been on the trunk and you should have had stable branch. Since the new development is already on the head this removes the need to merge (or put) new development there. However, to solve your current problem you will have to write a script. Assuming that you have a workspace already checked out on the head, this is how you put the branch version of a file to the head: cvs update -p -r branch-tag foo.c foo.c You will have to iterate this over every file in the tree. Once all the files are updated you can check in the whole repository. -- Stephen Rasku E-mail: [EMAIL PROTECTED] Senior Software EngineerWeb:http://www.pop-star.net/ TGI Technologies ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Easiest way to move a branch to the trunk
On Fri, Feb 02, 2001 at 08:56:26AM -0800, Stephen Rasku wrote: Brian Murrel wrote: I know that this is shutting the barn door after the horses have gone but your new development should have been on the trunk and you should have had stable branch. Of course. It was a little more abstract that I previously eluded but your points are right on. Both the trunk and the branch were parallel development, one only cutting edge, the other bleeding edge. I should have forseen moving the bleeding edge to the cutting edge though and did it as you said. Since the new development is already on the head this removes the need to merge (or put) new development there. Right. However, to solve your current problem you will have to write a script. Assuming that you have a workspace already checked out on the head, this is how you put the branch version of a file to the head: cvs update -p -r branch-tag foo.c foo.c Looks good. You will have to iterate this over every file in the tree. Once all the files are updated you can check in the whole repository. But what to do about files that are on the head but not in the branch and vice versa? Figure out which ones are which and do some "cvs new" and "cvs delete"s? Once I have done that I will correct the function of the branches. Thanx, b. -- Brian J. Murrell ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Easiest way to move a branch to the trunk
Brian Murrel wrote: But what to do about files that are on the head but not in the branch and vice versa? Figure out which ones are which and do some "cvs new" and "cvs delete"s? If you cvs update -p a file that only exists on the branch it will create it. If you do: cvs status new-file it will show: cvs server: use `cvs add' to create an entry for local.h If you cvs update -p a file that doesn't exist on the branch, you will get a zero length file. These should be good clues as to which files to add and delete. By the way, what's with the weird e-mail addresses (e.g. [EMAIL PROTECTED])? -- Stephen Rasku E-mail: [EMAIL PROTECTED] Senior Software EngineerWeb:http://www.pop-star.net/ TGI Technologies ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Easiest way to move a branch to the trunk
On Fri, Feb 02, 2001 at 11:37:29AM -0800, Stephen Rasku wrote: Brian Murrel wrote: If you cvs update -p a file that only exists on the branch it will create it. If you do: cvs status new-file it will show: cvs server: use `cvs add' to create an entry for local.h If you cvs update -p a file that doesn't exist on the branch, you will get a zero length file. These should be good clues as to which files to add and delete. So what I was thinking is true. Thanx. By the way, what's with the weird e-mail addresses (e.g. [EMAIL PROTECTED])? It's a "onetime" address. When I mail to unknown destinations (which includes lists -- which allow anonymous posting anyway) a unique return address is created for that message and it is logged. If the address starts attracting spam at some point, a) I know where the leak is b) I can turn it down (assuming it's outlived it's usefulness) to prevent the spam from successfully even being delivered to may mail server or c) I can add it to my spam-traps for early detection and resistance of spam sources. b. -- Brian J. Murrell ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Easiest way to move a branch to the trunk
On Fri, Feb 02, 2001 at 05:07:31AM -0800, Brian J. Murrell wrote: I have a project/repository which has a main branch (trunk) for stable, released versions and a development branch. The development branch was branched off of the main branch a while ago for development and has going along gangbusters. Now it is time to release. What is the easiest way to move the develoment branch onto the main branch so that what is on the main branch is completely replaced by the development branch. I realize of course I could use "cvs update -j" to move it all over but that is going to create a boatload of conflicts. I can deal with conflicts easily (and tediously) enough but I wonder why I should need to bother. It seems that I should be able to simply replace the contents of the main branch with the development branch in an easier way, no? All suggestions welcome, thanx. Here are some instructions I recently posted for someone else, lightly edited to reflect your situation, which is somewhat different from theirs: - Create a directory containing the latest development source, WITHOUT any CVS subdirectories (use "cvs export", or manually delete the CVS subdirectories from a preexisting sandbox). I'll call this dev. - Create another sandbox on the trunk (ie. the stable version), eg. using "cvs co" with no -r or -D options, or "cvs update -A". This sandbox is hereafter referred to as stable. - Get a list of the stable files you've deleted in development: % cd stable; find . -print | sort /tmp/stable % cd dev; find . -print | sort /tmp/dev % comm -23 stable dev /tmp/deleted-files - Recursively copy dev (new files, modified files, unmodified files -- the whole works) OVER TOP OF your stable sandbox; this will result in stable containing your development source, but with its CVS admin info pertaining to the stable version (not quite -- any files you've deleted in development will still be present; we'll deal with this momentarily) - Now, "cd stable; cvs -nq update" will give you a complete list of the files you've added (flagged by "?") and changed (flagged by "M") -- but NOT the ones you've deleted, which is why you had to make a list of those before overlaying the two directories - "cvs add" any of the "?"-flagged files that should be CVS-tracked (exclude any cruft that's made it into dev -- temporary files that people forgot to delete, etc.) - "cvs remove -f" the files you've deleted in development, ie. the ones in the list you made above (though of course you'll want to verify that none of them were deleted by accident in the distant past :-) - "cvs commit" -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Interviewer: You've been looking at the stars all your life: Is there anything in astrology? Arthur C. Clarke: It's utter nonsense. But I'm a Sagittarius, so I'm naturally skeptical. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Easiest way to move a branch to the trunk
Lo, on Friday, February 2, Brian J. Murrell did write: I have a project/repository which has a main branch (trunk) for stable, released versions and a development branch. The development branch was branched off of the main branch a while ago for development and has going along gangbusters. Now it is time to release. What is the easiest way to move the develoment branch onto the main branch so that what is on the main branch is completely replaced by the development branch. We're about to have to do this at work ourselves, because the folks who created the branch didn't really understand what they were doing, and so got the trunk branch backwards. (New development has been on the branch---evil!) If you tagged the trunk at the point where you branched, then this should actually be pretty easy. Call the tag PRE-BRANCH-TAG: * Get a working copy on the trunk; make sure there are no uncommitted changes. * If you want to preserve that line of development, you may want to tag and branch here. * Back on the trunk, roll back all changes made since the branch: cvs update -j HEAD -j PRE-BRANCH-TAG * Resolve any conflicts, although I'd suspect that there wouldn't be any. You may also want to commit here, but that's up to you. * cvs update -j PRE-BRANCH-TAG -j DEVELOPMENT-BRANCH to incorporate all changes made on the development branch. Again, there shouldn't be any conflicts. * commit. If you *don't* have PRE-BRANCH-TAG, then you're up a creek, and you'll have to go with one of the other more labor-intensive suggestions posted. Richard ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Too Frequently Asked Question of info-cvs mailing list
I'm answering to both of you :) "LS" == Laine Stump [EMAIL PROTECTED] writes: LS I've taken Jerry Nairn's vss2cvs.pl script, which you have on your LS website, and enhanced it quite a bit. It is now available at LShttp://www.laine.org/cvs/vss2cvs "CH" == Curt Hagenlocher [EMAIL PROTECTED] writes: CH I have made some important fixes to vss2rcs.js. You can get a CH newer version for your web site at CH http://www.hagenlocher.org/software/vss2rcs.js I have updated the faq entry and it now looks like this: === Q: I have a large MS Visual SourceSafe repository. How could I convert it to use it from CVS? A: There are two different scripts for that purpose: Laine Stump laine+info-cvs(at)laine.org has taken scripts originally written in Perl by Jerry Nairn jnairn(at)realnames.com, and enhanced it quite a bit. The result is available at: http://www.laine.org/cvs/vss2cvs/ Curt Hagenlocher curt(at)hagenlocher.org has written in JavaScript another script, which is available at: http://www.hagenlocher.org/software/vss2rcs.js === I will also delete the directory with my collection from server, to get rid of any confusion (Heiko Nardmann's tool appeared to just list files in VSS repository). I will also unregister my "project" vss-to-cvs at http://freshmeat.net. Laine, Curt, please, take a time to register your scripts at http://freshmeat.net/, to ease searching. Thank you! --alexm ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
pserver passwd
Hi How to connect to a remote system and setting of password for CVS .when i connect a remote system i want the information that how to set the cvspassword in server side while i accessin the repository from client. i have an message while connetion with the server failure aborted with the peer machine cvs -d :pserver:[EMAIL PROTECTED]:/usr/local/atest/cvsmain login (Logging in to [EMAIL PROTECTED]) CVS password: cvs [login aborted]: recv() from server lor.kovaiteam.com: Connection reset by p eer by arul ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: pserver passwd
[EMAIL PROTECTED] writes: cvs [login aborted]: recv() from server lor.kovaiteam.com: Connection reset by peer There's something wrong with your server. If it's running CVS 1.10.6, pserver is broken and you must update: you can get the current version (1.11) from www.cvshome.org. Otherwise, see the manual: http://www.cvshome.org/docs/manual/cvs_21.html#SEC182 -Larry Jones ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
