[info-cvs] Digest Number 266

[fabian . gilbeau]

How do I unsubscribe from [info-cvs] Digest ?

Tx.


address@hidden
07/10/2000 07:00 GMT
Please respond to address@hidden

To:   address@hidden
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" <address@hidden>
      2. Re: Repository know who has checkouts?
           From: "Noel L Yap" <address@hidden>
      3. RE: cvs add `find ./`
           From: "Pyatt, Scott" <address@hidden>
      4. Re: Repository know who has checkouts?
           From: "Derek R. Price" <address@hidden>
      5. Checkout a single file....
           From: address@hidden
      6. Re: Checkout a single file....
           From: address@hidden (Larry Jones)
      7. CVS_USER
           From: Jim Kingdon <address@hidden>
      8. Re: cvs add `find ./`
           From: Gerhard Sittig <address@hidden>
      9. cvs diff output PATCH input? (was: synchronize two repositories)
           From: "Robert Bresner" <address@hidden>


________________________________________________________________________
________________________________________________________________________

Message: 1
   Date: Fri, 06 Oct 2000 12:24:14 -0400
   From: "Derek R. Price" <address@hidden>
Subject: Re: Repository know who has checkouts?

Laird Nelson wrote:

> ----- Original Message -----
> From: "Derek R. Price" <address@hidden>
> > 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:address@hidden     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
address@hidden
http://mail.gnu.org/mailman/listinfo/info-cvs


________________________________________________________________________
________________________________________________________________________

Message: 2
   Date: Fri, 6 Oct 2000 13:05:23 -0400
   From: "Noel L Yap" <address@hidden>
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




address@hidden on 2000.10.06 11:43:34

To:   address@hidden
cc:   address@hidden, address@hidden
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:address@hidden     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
address@hidden
http://mail.gnu.org/mailman/listinfo/info-cvs


________________________________________________________________________
________________________________________________________________________

Message: 3
   Date: Fri, 6 Oct 2000 10:33:37 -0700
   From: "Pyatt, Scott" <address@hidden>
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:address@hidden
Sent: Friday, October 06, 2000 6:33 AM
To: address@hidden
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
address@hidden
http://mail.gnu.org/mailman/listinfo/info-cvs

_______________________________________________
Info-cvs mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/info-cvs


________________________________________________________________________
________________________________________________________________________

Message: 4
   Date: Fri, 06 Oct 2000 14:35:39 -0400
   From: "Derek R. Price" <address@hidden>
Subject: Re: Repository know who has checkouts?

Laird Nelson wrote:

> ----- Original Message -----
> From: "Derek R. Price" <address@hidden>
> > 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:address@hidden     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
address@hidden
http://mail.gnu.org/mailman/listinfo/info-cvs


________________________________________________________________________
________________________________________________________________________

Message: 5
   Date: Fri, 06 Oct 2000 18:51:56 -0000
   From: address@hidden
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
address@hidden
http://mail.gnu.org/mailman/listinfo/info-cvs


________________________________________________________________________
________________________________________________________________________

Message: 6
   Date: Fri, 6 Oct 2000 15:59:58 -0400 (EDT)
   From: address@hidden (Larry Jones)
Subject: Re: Checkout a single file....

address@hidden 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
address@hidden
http://mail.gnu.org/mailman/listinfo/info-cvs


________________________________________________________________________
________________________________________________________________________

Message: 7
   Date: Fri, 6 Oct 2000 18:29:58 -0400 (EDT)
   From: Jim Kingdon <address@hidden>
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
address@hidden
http://mail.gnu.org/mailman/listinfo/info-cvs


________________________________________________________________________
________________________________________________________________________

Message: 8
   Date: Fri, 6 Oct 2000 23:06:36 +0200
   From: Gerhard Sittig <address@hidden>
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" address@hidden
--
     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
address@hidden
http://mail.gnu.org/mailman/listinfo/info-cvs


________________________________________________________________________
________________________________________________________________________

Message: 9
   Date: Fri, 06 Oct 2000 22:07:00 -0500
   From: "Robert Bresner" <address@hidden>
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
address@hidden
http://mail.gnu.org/mailman/listinfo/info-cvs


________________________________________________________________________
________________________________________________________________________