How do I unsubscribe from [info-cvs] Digest ? Tx. [EMAIL PROTECTED] 07/10/2000 07:00 GMT Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: [info-cvs] Digest Number 266 -------------------------- eGroups Sponsor -------------------------~-~> Get free updates on your stocks from any phone with Tellme! Click here and you can even personalize these quotes. http://click.egroups.com/1/9536/4/_/1533/_/970902047/ ---------------------------------------------------------------------_-> There are 9 messages in this issue. Topics in this digest: 1. Re: Repository know who has checkouts? From: "Derek R. Price" <[EMAIL PROTECTED]> 2. Re: Repository know who has checkouts? From: "Noel L Yap" <[EMAIL PROTECTED]> 3. RE: cvs add `find ./` From: "Pyatt, Scott" <[EMAIL PROTECTED]> 4. Re: Repository know who has checkouts? From: "Derek R. Price" <[EMAIL PROTECTED]> 5. Checkout a single file.... From: [EMAIL PROTECTED] 6. Re: Checkout a single file.... From: [EMAIL PROTECTED] (Larry Jones) 7. CVS_USER From: Jim Kingdon <[EMAIL PROTECTED]> 8. Re: cvs add `find ./` From: Gerhard Sittig <[EMAIL PROTECTED]> 9. cvs diff output PATCH input? (was: synchronize two repositories) From: "Robert Bresner" <[EMAIL PROTECTED]> ________________________________________________________________________ ________________________________________________________________________ Message: 1 Date: Fri, 06 Oct 2000 12:24:14 -0400 From: "Derek R. Price" <[EMAIL PROTECTED]> Subject: Re: Repository know who has checkouts? Laird Nelson wrote: > ----- Original Message ----- > From: "Derek R. Price" <[EMAIL PROTECTED]> > > The example is three > > teams at the same company sharing a CVS repository. Two use 'cvs > watch' by > > default and one does not. > > So how about making it part of the modules file? You'd certainly be creating some complex cases. If a dir was a member of two modules, one with watch on and one with watch off, which do you use? If two modules are members of a larger module, and all three have watch settings, does the lower granularity setting override, or no? If you could find a way to implement this that wouldn't screw up backwards compatibility, I'd certainly have no objections, but again, why bother? If you have your granularity such that you don't want 'watch on' inherited from $CVSROOT, you have to type 'cvs watch on' once at the toplevel of the new module (where module=directory in the simlest case) and everything below will have watch on from then on. I'd think that that was easier than adding a module description to the modules file. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- It's always darkest before dawn. So if you're going to steal the neighbor's newspaper, that's the time to do it. _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ________________________________________________________________________ ________________________________________________________________________ Message: 2 Date: Fri, 6 Oct 2000 13:05:23 -0400 From: "Noel L Yap" <[EMAIL PROTECTED]> Subject: Re: Repository know who has checkouts? OK, I think the following solution might satisfy all: If "Watch=On" is in CVSROOT/config, then everything within the repository is watched. There is no need to update or search through the fileattr files. "cvs watch on/off" emits an error. If "Watch=On" is not in CVSROOT/config, then everything works as it does now. Note that I am not volunteering to implement any solution -- I'm just helping to hash out a solution. Noel [EMAIL PROTECTED] on 2000.10.06 11:43:34 To: [EMAIL PROTECTED] cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Repository know who has checkouts? Noel L Yap wrote: > What about getting rid of "cvs watch on/off" altogether and making this feature > a configuration parameter inside CVSROOT/config? I wouldn't object to a parameter to change the default watch status or the like if it didn't remove the old behavior, but it doesn't seem necessary. See below. > The main difference I see is > the granularity of "cvs watch on/off". However, I think teams tend to use "cvs > watch on/off" for the entire repository, anyway. In fact, I think there may be > a feature (or bug) in which new modules do not get "cvs watch on" if the team > already deems all modules to have "cvs watch on". I was just playing around and it seems that 'cvs watch' stores a 'fileattr' for each directory as well as for each file and that this is where the watched status for new files and directories is inherited from. I also double checked that this can be applied to the top level directory, so why not: cvs co -l . cvs watch on to make sure that new modules inherit the repository watch status? As for the current granularity, I think it is important. The example is three teams at the same company sharing a CVS repository. Two use 'cvs watch' by default and one does not. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I will never win an emmy. I will never win an emmy. I will never win an emmy... - Bart Simpson on chalkboard, _The Simpsons_ This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan & Co. Incorporated, its subsidiaries and affiliates. _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ________________________________________________________________________ ________________________________________________________________________ Message: 3 Date: Fri, 6 Oct 2000 10:33:37 -0700 From: "Pyatt, Scott" <[EMAIL PROTECTED]> Subject: RE: cvs add `find ./` An optimization of this would be to perform the find from within the Perl script. That way the opening, compiling and closing of foo.pl happens once. I've found that find.pl is fast under the Unix platforms I've tried but surprisingly slow under NT. If I need speed under NT I do something like this: @findResults = `find . -type f -exec foo.pl {} \;`; In this case "find" is from the Cygwin or MKS tools. -Scott -----Original Message----- From: Richard J. Duncan [mailto:[EMAIL PROTECTED]] Sent: Friday, October 06, 2000 6:33 AM To: [EMAIL PROTECTED] Subject: Re: cvs add `find ./` > Is there any way to tell CVS that I want to > add only new files to the repository? Perhaps if > I "cvs diff $file" and check the error level for > each file? One easy way is to run `cvs status <file>` and grep for "Status: Unknown." Pipes don't work well in a find command, so I generally write a quick script for this sort of thing: #!/usr/local/bin/perl # file: foo.pl $file = shift; open(FP,"cvs status $file|") or die "cannot run cvs status: $!"; while (<FP>) { if (/Status: Unknown/) { system "cvs add $file"; close(FP); exit; } } close(FP); Then run, find . -type f -exec foo.pl {} \; -Rick _______________________________________________ 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 ________________________________________________________________________ ________________________________________________________________________ Message: 4 Date: Fri, 06 Oct 2000 14:35:39 -0400 From: "Derek R. Price" <[EMAIL PROTECTED]> Subject: Re: Repository know who has checkouts? Laird Nelson wrote: > ----- Original Message ----- > From: "Derek R. Price" <[EMAIL PROTECTED]> > > If you have your granularity such that you don't want > > 'watch on' inherited from $CVSROOT, you have to type 'cvs watch on' > once > > at the toplevel of the new module (where module=directory in the > simlest > > case) and everything below will have watch on from then on. > > Until some other user came along and typed cvs watch off. I'm just > looking for a sensible way to protect who can turn watches on and off. > Right now it can't be protected at all. Noel's config file solution (perhaps with Watch=off & Watch=dynamic extensions) might be the happy medium then, but enabling restriction of the watch on/off commands to particular users seems the most robust. Note that I'm not offering to implement anything either. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- We hold these truths to be self-evident, that all men are created equal; that they are endowed by their Creator with inherent and inalienable rights; that among these, are life, liberty, and the pursuit of happiness; that to secure these rights, governments are instituted among men, deriving their just powers from the consent of the governed; that whenever any form of government becomes destructive of these ends, it is the right of the people to alter or abolish it, and to institute new government, laying its foundation on such principles, and organizing its powers in such form, as to them shall seem most likely to effect their safety and happiness. - Declaration of Independence, as written by Thomas Jefferson, 1776 _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ________________________________________________________________________ ________________________________________________________________________ Message: 5 Date: Fri, 06 Oct 2000 18:51:56 -0000 From: [EMAIL PROTECTED] Subject: Checkout a single file.... Hello, CVS can't checkout a single file, isn't it? It only allows to checkout a whole project (module).... Does any one knows a similar tool which permits to checkout a single file, and which have locks over files? The server should run on Linux and clients on windows. TIA, Victor Batista _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ________________________________________________________________________ ________________________________________________________________________ Message: 6 Date: Fri, 6 Oct 2000 15:59:58 -0400 (EDT) From: [EMAIL PROTECTED] (Larry Jones) Subject: Re: Checkout a single file.... [EMAIL PROTECTED] writes: > > CVS can't checkout a single file, isn't it? It only allows to > checkout a whole project (module).... Nope, CVS is happy to let you check out a file, a directory, or a tree. -Larry Jones What's Santa's definition? How good do you have to be to qualify as good? -- Calvin _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ________________________________________________________________________ ________________________________________________________________________ Message: 7 Date: Fri, 6 Oct 2000 18:29:58 -0400 (EDT) From: Jim Kingdon <[EMAIL PROTECTED]> Subject: CVS_USER I'd like to propose checking in the patch at http://www.cvshome.org/cyclic/cvs/dev-user.txt There is lots more discussion at http://www.cvshome.org/cyclic/cvs/dev-user2.txt My summary/reaction is that setting CVS_USER in the environment is the way to provide the cvs username. And the dev-user.txt patch is a good enough way to do that. _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ________________________________________________________________________ ________________________________________________________________________ Message: 8 Date: Fri, 6 Oct 2000 23:06:36 +0200 From: Gerhard Sittig <[EMAIL PROTECTED]> Subject: Re: cvs add `find ./` On Fri, Oct 06, 2000 at 08:33 -0500, Richard J. Duncan wrote: > > Then run, > > find . -type f -exec foo.pl {} \; An exec for every single item found is quite expensive (don't know about today's timing, but I would estimate some 10 msec for creating a new process -- the perl compiler run adds to this, too). Get yourself trained to use the xargs(1) command. It will balance between too many program invocations and too long command lines ("foo.pl `find ...`" doesn't work for some 4K arguments on the platforms I've seen.). find . -type f -print0 | xargs -0 foo.pl virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED] -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ________________________________________________________________________ ________________________________________________________________________ Message: 9 Date: Fri, 06 Oct 2000 22:07:00 -0500 From: "Robert Bresner" <[EMAIL PROTECTED]> Subject: cvs diff output PATCH input? (was: synchronize two repositories) I'm dealing with the problem right now... My company has its repository, and another company has taken control of a branch of our repository. So, we cvs exported the branch, and they created their own repository from that export. Now their files are all at version 2.1 (don't ask) while our files are 1.x.x.x etc. (Would CVSUp be able to deal with that?) Now, both companies will be developing enhancements and bug fixes for a while, us in our branch, them in their mainline. And we're gonna keep these bad-boys in sync. With a magical perl script, my friend. I've got it almost finished, with only one remaining issue -- I'm a tad weak on the whole patch utility. So. Is there a way to get "cvs diff" to output information that can then be used by patch? So: Repo A Repo B --------------- ----------------- foo.c (2.1) foo.c (1.233.2.18) Lets say (A) foo.c gets checked in and is now at 2.2. My perl script will want to get the diffs of foo.c from 2.1 to 2.2 and apply THOSE changes to (B) foo.c 1.233.2.18. This script should be done by Monday if I can figure out how to do this last piece, and (my bosses permitting) I'd be happy to put it up to this list if anyone else would find it helpful. More details if your interested: Two repositories, on two seperate cvs servers. One client machine, with both repositories checked out to a local area. cvsynch.pl init Creates */CVS/SyncRoot and */CVS/SyncEntries files. SyncRoot contains the path to the directory that must be kept in sync with the current dir. SyncEntries looks like this: file_name/Repo_A_Revision_Number/Repo_B_Revision_Number SyncEntries info shows when the file in the two repositories was last sync'd. If the file has changed, and those changes have been checked in, then the SyncEntries revision number will not match the CVS/Entries revision number, indicating that a sync needs to happen. If the file only changed on one side, then I can just copy over the file in the other area and check that it. But, if it's changed in both areas, I need to PATCH one direction, then I can copy that patched file back. Tada? Sure, if I can get that patch working. Of course there's more details than just that, but I reckon that's the gist. Thanks, Rob W.Pr�pper wrote: > > We have the problem that we have to synchronize the sources of two > repositories. We are two independant companies with their own cvs > repositories and we build the software with the sources of both > repositories. I think there are two possibilities: > > 1. checkout from both repositories and building the software with both > working directories > > 2. checkout one repository and import it to the other > > Are there any other ways to synchronize the repositories ? Are there any > experinces with the same or a similar problem ? > > Thanks for answering > > Wolf _______________________________________________ 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
