Can I check out a new directory without getting the files in it?
I'm trying to find a way to check out a new directory without checking out the files within that directory. I currently execute "cvs co - l ", which gets the directory, but also any files that exist in it. There's -d, but that only gets empty directories. Is there a way to check out only the directory even if it contains files? Alternatively, checking out the directory with just one specific file in it could be adapted to what we need. But we can't have it retrieve every file. Thanks. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS History logging
I need to know what files and the commands to specify in the files for logging the history of changes in source files. I suspect this is need for CFR auditing. The URL below should have this information. Specifically, when a file is committed to CVS I need the commit comment from the user placed into the source file. My hope is that the comment will be placed on the alter blocks as seen by a CVS diff. The only files that should be impacted by this are *.h and *.cpp files. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: merge mode for XML
> "Noel" == Noel Yap <[EMAIL PROTECTED]> writes: >> If CVS had away to use modular plug in "diff" and "merge" >> programs, we could setup a wrapper file that would >> automatically diff/merge the file differently based on the >> extension. e.g.: >> >> *.xml xml_dm *.html html_dm Noel> Ideally, the diff/merge tool would be tied to the type of Please add also a keyword-substitution tool to the check list. Noel> the file and the type of the file is initially set depending Noel> on the extension. No. Not on extension, but based on *regular expressions*, or at least shell-style pattern matching expressions. Extensions are too simplistic. (c.f. CVSROOT/cvswrappers, CVSROOT/cvsignore) Noel> This way, one would be able to change the Noel> type of the file independent of its extension. Yes. Some mechanisms like ~/.mime.types plus ~/.mailcap would be desirable. But one more complication would be the version of these external programs. Maybe, CVS needs to keep track of which version of the tools were used for which file revisions, so as to reliably and faithfully reproduce any snapshot. -- Lee Sau Dan §õ¦u´°(Big5)~{@nJX6X~}(HZ) E-mail: [EMAIL PROTECTED] Home page: http://www.informatik.uni-freiburg.de/~danlee ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Sharing the same physical file in multiple directories
I have one config file that must exist in several directories in my project. I would like to be able to have CVS create this file in all its locations and still only have it stored once in the repository. Any idea how or if I can do that. Thanks Paul Karsten ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
How to retain revision history when copying files from one cvs project to another?
Hi, We have all our source code in the CVS repository as one project. Now we want to start a new project in CVS. But we will be requiring files from the existing project into the new project. How can we copy/move the files over to the new project without losing their revision history? Is there a way to do this? Does the cvs import command work for doing this? Please let me know if anyone has an answer. Thanks, Vuppala. __ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: merge mode for XML
Hi, Greg: Greg A. Woods wrote: > [ On Wednesday, May 1, 2002 at 11:34:02 (-0400), Gary Bisaga wrote: ] > >>Subject: RE: merge mode for XML >> >>Good point, Noel. At my last job we had a partner we were required to >>connect to, and it was a job getting even an example XML document out of >>them, let alone a DTD or schema. > > > You guys are just re-iterating all the silly arguments that have come > and gone with EDI. New face, same old problem. > Yeah! been there seen that. What's the good of XML if there's no concert about the DTD/schema to be used!? -- SALUD, Jesus *** [EMAIL PROTECTED] *** Desde Zaragoza, busco empleo - http://www.geocities.com/jesusm_navarro/CV/cv.html *** ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Unable to add new files after checking out a tag
We bring a new tree up to date with the latest 'stamped' release by using "cvs update -r", where the release was created with "cvs tag -RF ". This seems to work for existing files. However, when people try to add a new file to the repository, they get the error "cannot add file on non-branch tag ". We've only ben able to fix it by erasing the tree and doing a cvs co. That gets the latest revision of every file though, which is not what we want. Is there a way to fix this? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS File Time stamp preserve ...
* Seema Agarwal <[EMAIL PROTECTED]> [2002-05-02 09:00]: > I'd like > to preserve the time stamp of the "incoming files" when putting them into > my repository. Is thereany way of doing this ? "import" is your friend. Use it along with the -d option. Ingolf PS: CC'ed to info-cvs as it is more appropriate there. -- Ingolf Steinbach Jena-Optronik GmbH [EMAIL PROTECTED] ++49 3641 200-147 PGP: 0x7B3B5661 213C 828E 0C92 16B5 05D0 4D5B A324 EC04 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Group permissions to branches
I'm not saying that you should not use a separate lock directory, just that it won't help you solve this problem. You cannot control access to branches using unix permissions, since the same RCS files contains all the branches. Users need write permission to the directories to commit to any branch. -Brian On Mon, Apr 29, 2002 at 07:17:26PM +0500, Muhammad Shakeel wrote: > Dear Brian, > Hi > > Sorry i am asking a question regarding a little old thread on mailing list. Can u >please explain why u r not recomending to use a option of using an alternate >directory for lock files, specially in this case. > > Regards, > shakeel > > > Brian Poynor wrote: > > >You can't really do this with the CVSROOT/passwd file. But if you are > >primarily concerned about who can commit to Branch A and Branch B (as > >opposed to checkout), you can implement that using CVSROOT/commitinfo. > > > >(I answered a similar request earlier, and discounted the option of > >using an alternate directory for lock files. This is one of the > >primary reasons why. You cannot use unix permissions to govern which > >branch a user can work on, which is a fundamental need in my > >experience. I believe this is the only mechanism in CVS for this.) > > > >Your commitinfo script can examing the CVS/Tag file. It's the trunk > >(mainline) if it doesn't exist, or doesn't have "T" as the first > >character in it, otherwise the branch name follows the "T". It is more > >work, but also more technically correct to examine the tag value in > >the CVS/Entries or CVS/Entries.Log file for each file being committed > >instead, since it is possible for a user to update a file from a > >different branch into her tree and commit it. The CVS/Tag doesn't > >necessarily reflect the branch of every file in the directory. > > > >An additional thing I check that all the files being committed are in > >the same branch, since committing to two different branches at once is > >almost always a result of user error, and it can be painful to > >correct. I figure they can commit twice if that is their intent. > > > >Once you know the branch of the file, you can check that the user is > >allowed to commit to that branch using a database of your own design > >(could be as simple as a text file with usernames for each branch). > > > >Just make sure that when your commitinfo scripts disallow a commit, > >they print a very clear error message to STDOUT. This will save you > >and your cvs users a lot of guesswork later. > > > >-Brian > > > >On Tue, Apr 09, 2002 at 12:33:07PM -0400, Danial Islam wrote: > > > >>I'm not sure if I posted this already, but here goes again: > >> > >>In my repository I have set up a main trunk with two branches coming out > >>of it, e.g. Branch A and > >>Branch B.Is it possible to restrict Branch A to a certain group of > >>users, and Branch B to another group of users? How would this be done > >>in UNIX? > >> > >>How would I modify the CVSROOT/passwd file to accomodate this? Right now > >>my passwd file currently has [unix ID]:[encoded password] for each user. > >> > >>Any help would really, really be appreciated! > >> > >> > >>Danial. > >> > >> > >>___ > >>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
Re: merge mode for XML
> "Paul" == Paul Sander <[EMAIL PROTECTED]> writes: Paul> A better implementation would be to code a symbolic name for Paul> the merge tool in a newphrase in the admin section the RCS Paul> file, and look up that symbolic name on the client to locate Paul> the proper tool. Good idea! There could be a look up table in CVSROOT to provide the defaults, and then the client will have its own config file to override the defaults. (Like CVSROOT/cvsignore vs. ~/.cvsignore.) -- Lee Sau Dan §õ¦u´°(Big5)~{@nJX6X~}(HZ) E-mail: [EMAIL PROTECTED] Home page: http://www.informatik.uni-freiburg.de/~danlee ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs remove: removing files not locally?
Hi! How can I remove a file in the repository without deleting it locally? Case: I check in a file by accident and want it removed from the repository. But I need the file. Think of it as per-user options regarding to a project. When I call remove the local file will be removed at my machine now and at all other users machines at the next update. I know that this will probably not be easy to solve - my thoughts: a) _every_ user has to backup the file for himself, one user removes it from the repository, all users restore the file (now a noncvs file) b) I remove the file from the repository (e.g. directly), _every_ user has to modify his CVS/Entries (remove the line) Both variants are critical because if they don't update the file or they don't remove it from CVS/Entries before updating the next time, cvs will delete the file. Any ideas? Regards, Stefan ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
read-only access on module basis in one repository
Hi folks, as I read on http://www.cvshome.org/docs/manual/cvs_2.html#SEC36 it is possible to gain read-only access to the repository for some users. I can´t find a hint on managing this for one repository based on modules. This is what I like to have: - user "A" read-write access to module "M-A" + "M-B" - user "B" read-only access to module "M-A" + read-write access to module "M-B" (Module "M-A" and module "M-B" are in the same repository) As I understand the docs mentioned above readers/writers files only affect the whole repository. They are not module dependend. Maybe I´m wrong, or there is another way to manage such situation. Any hints are welcome. Thanks. regards Andreas Thalau ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
FW: Extracting All Versions of a File From CVS
I'm trying to extract _all_ versions of a CVS file into a directory. Any ideas how to do this or whether it can be done? Many thanks. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: merge mode for XML
[Greg Woods]: >... conversations about XML and DTDs ... > ... > "well formed" by definition should mean in conformance to a > pre-existing DTD! > ... > Do you build relational databases without defining a schema? Well, I wrote Perl-SQL, a relational database system that is self-schematizing - where every record can define its own schema, with its own fields. Motivation: schema changes in most existing relational databases are onerous. Even just adding fields is painful. Self-schematization allows new fields to be added on the fly, improving documentation of the experiment results that are my target data, because any observed features can be easily added to the schema in a structured way. As opposed to all of those database schemas that have a miscellaneous text or comment field, where far too often all the critical data that you wish to process lives. Self-schematization allows you to do all SQL operations across spontaneously added fields. --- 3-4 years ago I discussed self-schematization with Prof. David Dewitt, a man of some reknown in database circles. His take is that self-schematization was not done in the early days to save space, and that now it is not unreasonable to do so. However, rather than Perl-SQL, he pointed to me towards XML, saying something like "well formed SQL doesn't require a schema or DTD -- that is the future." --- I.e., Greg, not all RDBMS experts agree with you about schemas; ditto DTDs. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Moving a module from one repository to another
Hello NG, is there a chance to move a module from one repository to another? I want to create different repositories for each development environment, and so I must splitt my old repository. Of course I could simply checkout a modul and import it to the new repository - but all my old revisions and tags get lost this way. Thanks for any help BTW is there a faq for this group? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: merge mode for XML
> "Sean" == Sean Hager <[EMAIL PROTECTED]> writes: Sean> I agree that XML is overkill, but the truth is that it is Sean> here to stay. Sean> XML is fastly becoming excepted as the defacto standard for . "accepted"? :) Sean> If CVS had away to use modular plug in "diff" and "merge" Sean> programs, we could setup a wrapper file that would Sean> automatically diff/merge the file differently based on the Sean> extension. Yeah. That'd be a cool feature. But then, CVS will no longer be a standalone program. If you move the repository to another server where the modules are missing, how would you expect CVS to behave? Consider the case where programmers are working on UNIX workstations with an NFS mounted CVS repository. The "cvs" command just runs locally, without using the CVS client-server operations. In this case, it is possible that those pluggable modules are present on some workstations but not the others. So, files commited from one machine may fail to check out in another. And how can we now make sure the snapshots (tags) is really reproducible, when CVS now depends on extension modules? Some more thoughts have to be made before it becomes reliable. Some more changes to the current architecture will be needed. This is not a simple change. Of course, I'm not saying pluggable extension modules is a bad thing. And it would be also nice to have keyword-substitution modules, too, so that we can keep $Id$ as comment tags in GIF/JPEG/PNG/TIFF, for instance. But some major redesign of CVS would be required to manage the which versions of which modules were used to commit which changes, so that CVS could faithfully and reliably reproduce the snapshots. -- Lee Sau Dan §õ¦u´°(Big5)~{@nJX6X~}(HZ) E-mail: [EMAIL PROTECTED] Home page: http://www.informatik.uni-freiburg.de/~danlee ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: splitting CVSROOT/modules into multiple files?
On Fri, 26 Apr 2002 15:21:44 -0400, "Frederic Brehm" <[EMAIL PROTECTED]> wrote: >At 0:42 +0200 4/26/02, Andreas Thalau wrote: >> >>We have a dozen (the number is continuously growing) projects with five >>up to ten sub-modules for each project in one repository and the modules >>file is getting more and more "unreadable". This is why we like to have >>it separated into one file per project. Maybe there are many more >>advantages when making this possible which we can´t figure out >>yet...(we´re new to cvs..) > ># > > >You can put lots of whitespace and lots of comment lines in a modules >file. Can't you increase the readability that way? > > ># Hi Fred, o.k. I think for now this is the easiest way to solve the problem of readability. Thanks for the hint. regards Andreas Thalau ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS diagraming tools
I'm hoping to untangle a CVS hairball and need a good charting tool that will allow me to run against a repository and generate a diagram. Is there anything out there that already does this? Thanks. Max ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: File Locking with CVS
Greg A. Woods" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]... > [ On Monday, April 29, 2002 at 15:48:37 (-0500), Gilroy, Michael -AES wrote: ] > > Subject: File Locking with CVS > > > > My manager won't let me use CVS with concurrent versions of files. I need > > to have the file locked when I edit the file (cvs edit) so that no one else > > can do a 'cvs edit' until I either do a 'cvs unedit' or a 'cvs commit'. > > This would be similar to the way SCCS and RCS work. > > Yes, it is. Perhaps you should be using SCCS or RCS instead of trying > to use the Concurrent Versions System. > I disagree. Take it one step at a time. Import the files. Do a cvs admin -L on all of them. Make sure everyone does cvs checkout -l. Once they get comfortable with sandboxes, start cvs admin -U some of the files, especially those you work on. That is what I am doing. I have set up locking for those who want it. I don't. I talk it up all the time. They'll come around. > > However, I also need > > some of the advanced features that only CVS can provide. > > There are litterally dozens of front-ends available for RCS (and some > for SCCS) that may provide all or most of the "advanced" features you > claim you need. Perhaps you should investigate using one of those other > front-ends with RCS (or SCCS). > > -- > Greg A. Woods > > +1 416 218-0098; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> > ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Any plan to merge cvspwd into cvs?
I have been using "cvspwd" to manage my CVS user accounts in my :pserver host so that I don't have to create Unix accounts for each CVS user. However, "cvspwd" can only be executed by the repository owner, which means each CVS user cannot change their own password... Is there any plan from the CVS team to include "cvspwd" into future releases of CVS and have a "cvs passwd" command for users to manage their own passwords? Ben ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
helmut schmidt/CH/SMAG ist außer Haus.
Ich werde ab 02.05.2002 nicht im Büro sein. Ich kehre zurück am 06.05.2002. Ich werde Ihre Nachricht nach meiner Rückkehr beantworten. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Moving CVS repository
[ On Thursday, May 2, 2002 at 18:01:03 (-0400), Larry Jones wrote: ] > Subject: Re: Moving CVS repository > > Greg A. Woods writes: > > > > It's irrelevant how they get that way. If all the files in given > > working directory hierarchy are not from the same repository then the > > user loses. > > In what sense? CVS has handled that just fine for quite some time now. only in its most basic form there are zillions of basically unsolvable issues which arise if there's any use of *info files. I seem to remember a discussion on this issue back in the dark ages about this issue and the resolution would be that such "accidents" would be officially unsupported. -- Greg A. Woods +1 416 218-0098; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Removing a branch
On Thu, May 02, 2002 at 05:59:21PM -0400, Danial Islam wrote: > What is the safest/best way to remove a branch full of files from the > repository? > > I was thinking that cvs rtag -d or cvs tag -d > are not sufficient enough. You're right. Those will only remove the branch tags; all the revisions will still be there -- but unlabelled now, so nobody will know what they signify. You'll have to go through and "cvs admin -o" all the revisions on the branch. But be careful! You could easily trash trunk revisions by mistake. And once trashed, they're trashed for good; "cvs admin -o" CANNOT be undone. It's probably better -- certainly safer -- to just leave the branch alone, and tell everyone to ignore it... -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Anyone who swims with the current will reach the big music steamship; whoever swims against the current will perhaps reach the source. - Paul Schneider-Esleben ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Moving CVS repository
Greg A. Woods writes: > > It's irrelevant how they get that way. If all the files in given > working directory hierarchy are not from the same repository then the > user loses. In what sense? CVS has handled that just fine for quite some time now. -Larry Jones There's a connection here, I just know it. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Removing a branch
What is the safest/best way to remove a branch full of files from the repository? I was thinking that cvs rtag -d or cvs tag -d are not sufficient enough. Danial. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Moving CVS repository
[ On Thursday, May 2, 2002 at 15:38:27 (-0500), Joi Ellis wrote: ] > Subject: Re: Moving CVS repository > > On Thu, 2 May 2002, Greg A. Woods wrote: > > > > If I'm not mistaken the CVS/Root file _MUST_ be identical throughout an > > entire module's working directory, regardless of whether module aliases > > are used or not. A given working directory _MUST_ always come from the > > same repository. > > > > (Of course idiot users could maybe manually check out one module from > > another repository into the same working directory, but they lose and > > that's just too bad for them, IMNSHO! :-) > > Yes, that is true. > > However, this isn't what I said. I said users often nest modules. It's irrelevant how they get that way. If all the files in given working directory hierarchy are not from the same repository then the user loses. It matters not whether they were checked out with a module alias (which automatically "nests modules"), or by hand, or whatever. What you've described doesn't seem to indicate any deviation from this rule. -- Greg A. Woods +1 416 218-0098; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Moving CVS repository
On Thu, 2 May 2002, Greg A. Woods wrote: > [ On Thursday, May 2, 2002 at 13:39:06 (-0400), Eric Siegerman wrote: ] > > Subject: Re: Moving CVS repository > > > > On Wed, May 01, 2002 at 01:42:44PM -0500, Joi Ellis wrote: > > > find . -type f -name 'Root' | \ > > > xargs perl -pi.bak -e 's/localhost/some.hostname/' > > > [...] > > > I prefer using perl rather than a 'cp' because some of our modules > > > are nested and I don't trust the Root file to be identical all > > > through the tree. Maybe they are, maybe they aren't. > > > > Agreed. > > If I'm not mistaken the CVS/Root file _MUST_ be identical throughout an > entire module's working directory, regardless of whether module aliases > are used or not. A given working directory _MUST_ always come from the > same repository. > > (Of course idiot users could maybe manually check out one module from > another repository into the same working directory, but they lose and > that's just too bad for them, IMNSHO! :-) Yes, that is true. However, this isn't what I said. I said users often nest modules. This is particularly common in Java applications. There is at least one IDE that leads its users into building such bastard workspaces. I see this come up a lot on the JBuilder newsgroups because JBuilder doesn't support nested modules well (if at all) but users are trying to coerce JBuilder into adjusting itself to an existing nested workspace. Module A: dirA1 dirA2 Module B: dirB1 dirB2 Workspace: dirA1 dirA2 dir B1 dir B2 In this sort of nested workspace, one can't simply cp a Root file from the top of the workspace into all of the subdirectories because B's Root is different. -- Joi EllisSoftware Engineer Aravox Technologies [EMAIL PROTECTED], [EMAIL PROTECTED] No matter what we think of Linux versus FreeBSD, etc., the one thing I really like about Linux is that it has Microsoft worried. Anything that kicks a monopoly in the pants has got to be good for something. - Chris Johnson ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Moving CVS repository
[ On Thursday, May 2, 2002 at 13:39:06 (-0400), Eric Siegerman wrote: ] > Subject: Re: Moving CVS repository > > On Wed, May 01, 2002 at 01:42:44PM -0500, Joi Ellis wrote: > > find . -type f -name 'Root' | \ > > xargs perl -pi.bak -e 's/localhost/some.hostname/' > > [...] > > I prefer using perl rather than a 'cp' because some of our modules > > are nested and I don't trust the Root file to be identical all > > through the tree. Maybe they are, maybe they aren't. > > Agreed. If I'm not mistaken the CVS/Root file _MUST_ be identical throughout an entire module's working directory, regardless of whether module aliases are used or not. A given working directory _MUST_ always come from the same repository. (Of course idiot users could maybe manually check out one module from another repository into the same working directory, but they lose and that's just too bad for them, IMNSHO! :-) -- Greg A. Woods +1 416 218-0098; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Upgrading to 1.11 from 1.10
In UNIX, if I had the repository and all the scripts set up in CVS 1.10, then if i start using the binary for CVS 1.11 during the middle of our code development, will my repository get screwed up? Danial ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [OT] Example for Perlwrapper around cvs login?
On Thu, 2 May 2002, Oliver Fischer wrote: > Sorry, may be a little bit offtopic... > > Does someone have example perl script to wrap cvs login via open2/3 > and IO::Select? I am not able to get my one working. > > Thanks... > Yes. Here's one I use in a SOAP-based distributed build system. I've expressed the routine and the stuff it calls as shell 'here' documents just because I'm feeling geeky today. My code is OO and passes in a target object whose fields contain the info needed to access the repository. You can easily change this to pass in the stuff as string scalars instead. To use: require cvsLogin.pl; require services.pl; &_cvsLogin( $target ); cat >cvsLogin.plrepository(); my $cmd = "export CVS_PASSFILE=$workDir/.cvspass; cvs -d $repository login"; my @input = ( $target->userpw() ); my ($i,$j) = &logTick( $cmd, $target->buildlog(), \@input, 0); } EOF cat >services.pl add(*KIDSTDOUT,*KIDSTDERR); print KIDSTDIN join("\n", @$input ), "\n"; push(@$output, &getsome( $selector, 0.25 ) ); $selector->remove(*KIDSTDOUT,*KIDSTDERR); close(KIDSTDIN); close(KIDSTDOUT); close(KIDSTDERR); waitpid($pid,0); my $ierr = $? >> 8; my $isig = $? & 255; my $msg = "Execution Summary:\n\tCmd=$cmd\n\tRC=$ierr\n\tSignal=$isig\n"; push(@$output,$msg); if ( $ierr != 0 ) { warn($msg) if $logWarnings; } return ($ierr,$isig); # # no input provided, do it the easy way, with backticks. # } else { push(@$output,"\n\$$cmd\n"); @foo = `( $cmd )2>&1`; push(@$output,@foo); my $ierr = $? >> 8; my $isig = $? & 255; my $msg = "Execution Summary:\n\tCmd=$cmd\n\tRC=$ierr\n\tSignal=$isig\n"; push(@$output,$msg); if ( $ierr != 0 ) { warn($msg) if $logWarnings; } return ($ierr,$isig); } } sub getsome { my ($selector)=shift; my ($wait)=shift || 0.5; my $output = ""; my @output = (); my @temp = (); my @ready = (); my $len = 0; my $buf = 0; #warn("Getsome checking selector."); while ( @ready = $selector->can_read( $wait )) { #warn( "Getsome has " . (scalar @ready ) . " file handles with waiting data "); foreach my $fh (@ready) { #if (fileno($fh) == fileno(KIDSTDOUT) ) { #$output = scalar ; #warn("calling sysread..."); #$len = sysread( KIDSTDOUT, $buf, 2048, 0 ); $len = sysread( $fh, $buf, 2048, 0 ); #warn( "GOT $len bytes: ", $buf ); $output .= $buf ; # } if ( $len == 0 ) { #warn( "EOF on filehandle detected, removed from selector" ); $selector->remove($fh); } } } @temp = split(/\n/,$output); foreach (@temp) { push(@output,$_ . "\n"); } # push(@output, split(/\n/,$output )); #warn("Getsome exiting"); return @output ; } 1; =back =head1 AUTHOR Joi Ellis =head1 BUGS Undoubtedly. =head1 REPORTING BUGS Send Email to Joi Ellis E[EMAIL PROTECTED]. =head1 COPYRIGHT Copyright © Aravox Technologies, Inc. =head1 SEE ALSO see-also links goes here EOF -- Joi EllisSoftware Engineer Aravox Technologies [EMAIL PROTECTED], [EMAIL PROTECTED] No matter what we think of Linux versus FreeBSD, etc., the one thing I really like about Linux is that it has Microsoft worried. Anything that kicks a monopoly in the pants has got to be good for something. - Chris Johnson ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Moving CVS repository
Eric Siegerman wrote: >On Wed, May 01, 2002 at 01:42:44PM -0500, Joi Ellis wrote: > >> find . -type f -name 'Root' | \ >> xargs perl -pi.bak -e 's/localhost/some.hostname/' >>[...] >>I prefer using perl rather than a 'cp' because some of our modules >>are nested and I don't trust the Root file to be identical all >>through the tree. Maybe they are, maybe they aren't. >> we have a rule in our base Makefile that fiddles with the file - and this works only on CVS Root files. .PHONY: fix_root fix_root: CVS/Root if [ X`cat $<` = X$(OLD_ROOT) ]; then echo $(NEW_ROOT) > $<; fi It's policy to have a Makefile that includes our base make file in every directory. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Moving CVS repository
On Wed, May 01, 2002 at 01:42:44PM -0500, Joi Ellis wrote: > find . -type f -name 'Root' | \ > xargs perl -pi.bak -e 's/localhost/some.hostname/' > [...] > I prefer using perl rather than a 'cp' because some of our modules > are nested and I don't trust the Root file to be identical all > through the tree. Maybe they are, maybe they aren't. Agreed. > It also makes it easier to repair damage should some foolish programmer > have a file named 'Root' with other content. The way to guard against that is to be more careful with the first, "selection", part of the pipeline, rather than the last, "action" part: find . -type f -print | grep '/CVS/Root$' | xargs [whatever] The "whatever" can be perl, cp, or anything else that makes sense (though I typically use perl, as shown above). -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Anyone who swims with the current will reach the big music steamship; whoever swims against the current will perhaps reach the source. - Paul Schneider-Esleben ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
[OT] Example for Perlwrapper around cvs login?
Sorry, may be a little bit offtopic... Does someone have example perl script to wrap cvs login via open2/3 and IO::Select? I am not able to get my one working. Thanks... Oliver ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: determining versions on checkin
David A Uebele writes: > > The problem I'm having is that I'd like to use remote cvs, and > so accessing the CVS/Entries file is no longer feasible. > I'm looking for suggestions about other ways to capture > the version of a file just checked in. I believe you can use "cvs -n status". -Larry Jones When I want an editorial, I'll ASK for it! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
running apache scripts linked with loginfo / commitinfo
Hi everyone, I am trying to run the apache scripts available at: http://cvs.apache.org/viewcvs.cgi/CVSROOT/ as you may guess/know, these scripts are linked with commitinfo, loginfo, etc. -- I tried to run this these on our system. The server is a Sun Solaris running cvs 1.11.1p1. The server runs perl, version 5.005_03 built for sun4-solaris. The client is a Linux Redhat 7.2 running cvs 1.11.1p1. Unfortunately scripts don't work properly. The scripts are running fine, but i believe one of the function does not do what it is intended to do. Here is a snippet from that function sub change_summary { local($out, @filenames) = @_; local(@revline); local($file, $rev, $rcsfile, $line); while (@filenames) { [...] >> open(RCS, "-|") || exec 'cvs', '-Qn', 'status', $file; << while () { if (/^[ \t]*Repository revision/) { chomp; @revline = split(' ', $_); $rev = $revline[2]; $rcsfile = $revline[3]; $rcsfile =~ s,^$CVSROOT/,,; $rcsfile =~ s/,v$//; } } close(RCS); [...] } The line marked (open(RCS, ..)) executes cvs -Qn status $file on the server. But CVS does not return any information when you try to execute this because it complains that it doesn't know about any CVS/Entries file. Because cvs status works only on a checked out copy. Since there is no such thing on the server, how can we expect this to work?? I believe there are some other problem associated with this scripts. It sends 2 files as an email. One has just the time/dat info, the other has a listing of the changed/renamed/added etc file with no summary info (no summary info because CVS status call does not work) -- What I have written above is my understanding of what is going on. If you have worked with these apache scripts, can you help me to make them work ? Any help is greatly appreciated. -arcin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs