cvs import error and permission error

[Bala Vignesh]

Hello friends !

 i have created my cvsroot under "cvs" account.
and i added required user under that(cvs) group.

but if i try to import files from another account it shows the error
cvs import :ERROR:can not write file ...  no such file or directory.

and also i gave g+rw permission to cvs dir . but often it changed
to  g-w . what is the reason?

Thank you,

balavignesh



___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS import for executables and binary files

[Russ Sherk]

On 4/18/05, Spiro Trikaliotis <[EMAIL PROTECTED]> wrote:
> Hello,
> 
> * On Mon, Apr 18, 2005 at 10:26:58AM +0530 Balaji D wrote:
> 
> > When I import few object files and exeuctables, through cvs import
> > command through command line, I dont get these files reflected in the
> > cvs area.
> >
> > Can some one help me to find out the option for importing those files.
> 
> Most probably, they are ignored because of the build-in ignore list if
> CVS, cf.
> https://www.cvshome.org/docs/manual/cvs-1.11.19/cvs_18.html#SEC178
> 
> If you set "-I !" in the command-line of "cvs import", the binary files
> should be handled, too.
> 
> > Also, I import .jar files into the cvs area, they donot reflect the
> > original size in the cvs area and even when I do a check out, their
> > sizes seem to be less...(For example a .jar of 393 KB is reflecting as
> > 7KB when I import to cvs and check it out).
> 
> .jar files are compiled java classes, aren't they? In this case, they
> are binary files, and they have to be handled like this. See

.jar file are Java ARchives.  Basically jars are zip archives
containing compiled java classes and other file resources.  As you
said, they need to be -kb'd.

Cheers,

--Russ

>   https://www.cvshome.org/docs/manual/cvs-1.11.19/cvs_9.html#SEC79
> and
>   https://www.cvshome.org/docs/manual/cvs-1.11.19/cvs_18.html#SEC166
> 
> HTH,
>Spiro.
> 
> --
> Spiro R. Trikaliotis  http://cbm4win.sf.net/
> http://www.trikaliotis.net/ http://www.viceteam.org/
> 
> 
> ___
> Info-cvs mailing list
> Info-cvs@gnu.org
> http://lists.gnu.org/mailman/listinfo/info-cvs
>


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS import for executables and binary files

[Spiro Trikaliotis]

Hello,

* On Mon, Apr 18, 2005 at 10:26:58AM +0530 Balaji D wrote:
 
> When I import few object files and exeuctables, through cvs import
> command through command line, I dont get these files reflected in the
> cvs area.
> 
> Can some one help me to find out the option for importing those files.

Most probably, they are ignored because of the build-in ignore list if
CVS, cf.
https://www.cvshome.org/docs/manual/cvs-1.11.19/cvs_18.html#SEC178

If you set "-I !" in the command-line of "cvs import", the binary files
should be handled, too.

> Also, I import .jar files into the cvs area, they donot reflect the
> original size in the cvs area and even when I do a check out, their
> sizes seem to be less...(For example a .jar of 393 KB is reflecting as
> 7KB when I import to cvs and check it out).

.jar files are compiled java classes, aren't they? In this case, they
are binary files, and they have to be handled like this. See

  https://www.cvshome.org/docs/manual/cvs-1.11.19/cvs_9.html#SEC79
and
  https://www.cvshome.org/docs/manual/cvs-1.11.19/cvs_18.html#SEC166

HTH,
   Spiro.

-- 
Spiro R. Trikaliotis  http://cbm4win.sf.net/
http://www.trikaliotis.net/ http://www.viceteam.org/


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

CVS import for executables and binary files

[Balaji D]

Hi All,

When I import few object files and exeuctables, through cvs import
command through command line, I dont get these files reflected in the
cvs area.

Can some one help me to find out the option for importing those files.

Also, I import .jar files into the cvs area, they donot reflect the
original size in the cvs area and even when I do a check out, their
sizes seem to be less...(For example a .jar of 393 KB is reflecting as
7KB when I import to cvs and check it out).

Please help

Regards
Balaji.


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

RE: cvs import issues

[Ryan Lea]

Sorry about the HTML (personally hate it myself but have gotten too used
to HTML based email clients and forgot it was switched to HTML - my
bad.)

The output from cvs import with -t is:

 -> main loop with CVSROOT=/export/home/cvsroot
      cvs [import aborted]: received abort signal
 -> Lock_Cleanup()

Cheers

-Original Message-
From: Larry Jones [mailto:[EMAIL PROTECTED] 
Sent: 13 April 2005 4:39 PM
To: Ryan Lea
Cc: info-cvs@gnu.org
Subject: Re: cvs import issues


Ryan Lea writes:
> 
> This is a multi-part message in MIME format.

Please do not send MIME and/or HTML encrypted messages to the list.
Plain text only, PLEASE!

> The actual checkouts/updates/add/commits etc all work fine.  However, 
> whenever 'cvs import' is run either remotely with :pserver: ... or 
> locally the import fails and cvs seg faults.

Please run a local import with tracing turned on (the -t global option)
and post the results.

-Larry Jones

Any game without push-ups, hits, burns or noogies is a sissy game. --
Calvin


This email has been scanned for all viruses by the MessageLabs service.


This email has been scanned for all viruses by the MessageLabs service. 



___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: cvs import issues

[Larry Jones]

Ryan Lea writes:
> 
> This is a multi-part message in MIME format.

Please do not send MIME and/or HTML encrypted messages to the list.
Plain text only, PLEASE!

> The actual checkouts/updates/add/commits etc all work fine.  However,
> whenever 'cvs import' is run either remotely with :pserver: ... or
> locally the import fails and cvs seg faults.

Please run a local import with tracing turned on (the -t global option)
and post the results.

-Larry Jones

Any game without push-ups, hits, burns or noogies is a sissy game. -- Calvin


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

cvs import issues

[Ryan Lea]

Title: Message



Hi,
 
We have recently 
upgraded to cvs client/server 1.11.19 from 1.10.8.  We have also moved out 
cvsroot from one machine to another.
 
The actual 
checkouts/updates/add/commits etc all work fine.  However, whenever 'cvs 
import' is run either remotely with :pserver: ... or locally the import fails 
and cvs seg faults.
 
I've checked the 
mailing archive and cant find anything to date.  Has anyone experienced 
this before at all or have a patch/workaround/solution??
 
thanks.
 
Settings:
    
CVSROOT=/export/home/cvsroot (I have complete access to this and can create 
directories using mkdir)
    CVS is sitting on a Solaris machine
    actual command being run is: 'cvs import -m "new version" 
jasperreports-0.6.5 branch version'
    There is plenty of disk space, memory, virtual memory, ability to open 
many files etc.
 

Ryan LeaWeb Developer
n 
Email: [EMAIL PROTECTED]n 
Tel: 0207 318 9080n 
Fax: 0207 318 9099
www.rightmove.co.uk 
- the UK's number 1 property website9 Park 
Place, St James's, London, SW1A 1LP
This 
message (including any attachments) is confidential and may be legally 
privileged. The content and 
views expressed are those of the sender and not necessarily rightmove.co.uk. If 
you are not the intended recipient, you must not disclose, copy or use any part 
of it. Please delete all copies immediately and notify the sender. Rightmove.co.uk 
Limited is registered in England and Wales, No. 03997679. Registered Office: 
Lavells House, 31 Hockliffe Street, Leighton Buzzard, LU7 1EZ.
 


This email has been scanned for all viruses by the MessageLabs service. 


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: cvs import problem

[C.G.Senthilkumar.]

Hi,
I found the solution.
The user is not considered a part of a new group until he logs out
and logs in again, which I didn't do. I just added the user to the
cvs group in the local machine and tried to import projects. I was
not able to import. Whereas if I tried it from remote machines, I
succeeded because, I was logging in each time I tried to import.
Thanks for pointing out the 'id' command.
Cheers,
Senthil.
On Fri, 18 Mar 2005, C.G.Senthilkumar. wrote:
Hi,
I'm seem to have tracked down the problem.
But I don't understand why this is happening
and what is the solution.
This is the output for id command when I'm
logged in locally to machine_A. The user is
'cheetanc'.
[EMAIL PROTECTED] cheetanc]$ id
uid=500(cheetanc) gid=500(cheetanc) groups=500(cheetanc)
   
This is the output for id command when I
ssh from machine_B to machine_A.
[EMAIL PROTECTED] cheetanc]$ id
uid=500(cheetanc) gid=500(cheetanc) groups=500(cheetanc),504(cvs)
   ^
You can see that the user cheetanc is part
of the group cvs in the second case when
not in the first case, (i.e) when logged in
locally. Here are the corresponding entries
in /etc/group.
[EMAIL PROTECTED] cheetanc]$ cat /etc/group | grep cheetanc
cheetanc:x:500:
cvs:x:504:cheetanc
Quite weird. What is happening?
Any help will be highly appreciated. Thanks in advance.
Thanks,
Senthil.
On Fri, 18 Mar 2005, Larry Jones wrote:
C.G.Senthilkumar. writes:
The repository's owner is root and group is cvs. The 'user' is in the
group cvs in the local machine A.
That makes it sound like the user is a member of the cvs group when
logged in with ssh but not when logged in locally.  You might want to
compare the results of running the ``id'' command both locally and via
ssh.
-Larry Jones
Girls are so weird. -- Calvin

--
Today's fortune:
Heights by great men reached and kept
Were not attained by sudden flight,
But they while their companions slept
Were toiling upward in the night.
-Longfellow
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: cvs import problem

[C.G.Senthilkumar.]

Hi,
I'm seem to have tracked down the problem.
But I don't understand why this is happening
and what is the solution.
This is the output for id command when I'm
logged in locally to machine_A. The user is
'cheetanc'.
[EMAIL PROTECTED] cheetanc]$ id
uid=500(cheetanc) gid=500(cheetanc) groups=500(cheetanc)

This is the output for id command when I
ssh from machine_B to machine_A.
[EMAIL PROTECTED] cheetanc]$ id
uid=500(cheetanc) gid=500(cheetanc) groups=500(cheetanc),504(cvs)
^
You can see that the user cheetanc is part
of the group cvs in the second case when
not in the first case, (i.e) when logged in
locally. Here are the corresponding entries
in /etc/group.
[EMAIL PROTECTED] cheetanc]$ cat /etc/group | grep cheetanc
cheetanc:x:500:
cvs:x:504:cheetanc
Quite weird. What is happening?
Any help will be highly appreciated. Thanks in advance.
Thanks,
Senthil.
On Fri, 18 Mar 2005, Larry Jones wrote:
C.G.Senthilkumar. writes:
The repository's owner is root and group is cvs. The 'user' is in the
group cvs in the local machine A.
That makes it sound like the user is a member of the cvs group when
logged in with ssh but not when logged in locally.  You might want to
compare the results of running the ``id'' command both locally and via
ssh.
-Larry Jones
Girls are so weird. -- Calvin
--
Today's fortune:
Heights by great men reached and kept
Were not attained by sudden flight,
But they while their companions slept
Were toiling upward in the night.
-Longfellow
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: cvs import problem

[Larry Jones]

C.G.Senthilkumar. writes:
> 
> 3. I tried to import a project from machine A into the repository on machine
>   A itself locally. cvs failed saying "can't create myproj directory,
>   permission denied".

Check the ownership and permissions of your repository directories --
the user you were running as doesn't have permission to create the
directory you were trying to import into.

> 4. I tried to repeat the last part except I set CVS_RSH=ssh and used cvs -d
>   :ext:[EMAIL PROTECTED]:/usr/local/repos even though I was importing in 
> a local
>   machine. And surprise! this trick worked.

That implies that you were not logged in as "user" when you tried the
local import.

-Larry Jones

I always have to help Dad establish the proper context. -- Calvin


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

cvs import problem

[C.G.Senthilkumar.]

Hi,
1. I set up a cvs repository in machine A.
2. I imported a project each from machine B and C into the repository using
:ext:(ssh) access control.
3. I tried to import a project from machine A into the repository on machine
A itself locally. cvs failed saying "can't create myproj directory,
permission denied".
4. I tried to repeat the last part except I set CVS_RSH=ssh and used cvs -d
:ext:[EMAIL PROTECTED]:/usr/local/repos even though I was importing in 
a local
machine. And surprise! this trick worked.
I have used the same username from all 3 machines to import projects.
What am I missing? I couldn't get any clue from Cederqvist.
Thanks,
Senthil.
--
Today's fortune:
Progress is impossible without change, and those who cannot change their
minds cannot change anything.
-- G.B. Shaw
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS Import using ANT

[Gunnar Ahlberg]

Hi

It's part of ant standard features - http://ant.apache.org/manual/index.html

Example:

  

/G

> Hi all,
>
> I'd like to use ANT to import periodically, our vendor sources to the
> CVS repository, but I haven't found any sample about "CVS Import" and
> "ANT script" on the web.
> Can somebody help ?
>
> Thanks
> Valerio
> ___
> Info-cvs mailing list
> Info-cvs@gnu.org
> http://lists.gnu.org/mailman/listinfo/info-cvs
>


/G

-
http://www.gunnarahlberg.com
-



___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

CVS Import using ANT

[valerio]

Hi all,

I'd like to use ANT to import periodically, our vendor sources to the
CVS repository, but I haven't found any sample about "CVS Import" and
"ANT script" on the web.
Can somebody help ? 

Thanks
Valerio
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Problems with CVS import with 1.12.9 and 1.12.10 releases

[Allen Sturtevant]

I'm having a problem with local-disk repository and
GSSAPI-server CVS imports.

When I import using the -ax and -tt flags with
the GSSAPI-server, the import fails with
"gss_unwrap failed".  See sample output below.

When I import using the -tt flag with a local-disk
repository, the import "looks" like it completes, but
still reports a problem (return status = 1, not 0).
See sample output below.

CVS 1.12.9 reports the GSSAPI problem above,
while CVS 1.12.10 doesn't report the problem
but simply hangs at the same point in the import.

As far as the local-disk import, both 1.12.9 and
1.12.10 fail in the same fashion -- with a bad
return status of 1.

As as test I'm importing the source distribution
for OpenLDAP 2.2.17 (~1,220 files and ~16.5 MB).
Smaller source distributions seem to work great
(return status of 0) while larger ones seem to
fail.

I'm running on Linux 2.4.20-p4smp-8chaos_19_7.

I care about the return codes from the CVS client
as I have a Perl wrapper script which calls "cvs
import" and checks for a good return status.

Any thoughts or experience on this, or what I
should try next?  :-}

Thank you,

Allen

=== CVS 1.12.9 GSSAPI-SERVER TEST ===

% (completely empty the CVSROOT directory)
% echo $CVSROOT
:gserver:server.llnl.gov:/tmp/cvs-root
% cvs init
% cvs -ax -tt import -ko -m "OPENLDAP Version 2.2.17"
stg/pub/openldap-2 openldap-2 openldap-2_2_17
...[lines deleted]...
  -> Sending file `xalloc.m4' to server
  -> Sending file `xsize.m4' to server
  -> Sending file `Makefile' to server
cvs [import aborted]: gss_unwrap failed
% echo $status
1
% 

=== CVS 1.12.9 LOCAL-DIRECTORY TEST ===

% (completely empty the CVSROOT directory again)
% echo $CVSROOT
/tmp/cvs-root
% cvs init
% cvs -tt import -ko -m "OPENLDAP Version 2.2.17" stg/pub/openldap-2
openldap-2 openldap-2_2_17
...[lines deleted]...
N stg/pub/openldap-2/tests/scripts/test019-syncreplication-cascade
N stg/pub/openldap-2/tests/scripts/test020-proxycache
N stg/pub/openldap-2/tests/scripts/test021-certificate
 
No conflicts created by this import
 
  -> Parse_Info (/tmp/cvs-root/CVSROOT/loginfo, stg/pub/openldap-2,
ALL)
  -> walklist ( list=0x80d3780, proc=0x806e164, closure=(nil) )
  -> Lock_Cleanup()
  -> remove_locks()
  -> Simple_Lock_Cleanup()
% echo $status
1
%
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Fuzziness on cvs import & empty directories

[Greg A. Woods]

[ On , October 27, 2004 at 08:03:13 (-0700), Jan Stap wrote: ]
> Subject: Fuzziness on cvs import & empty directories
>
> I'm trying to figure out how to import a set of empty directories into
> a CVS project.

Keep in mind that CVS does not manage directories -- it only manages the
files within them and directories are only used as placeholders.  They
exist when they need to and they go away automatically when they are no
longer needed (at least so long as you correctly use the "-d" and "-P"
options that really should be forced on all the time).

Also keep in mind that the very idea of using "cvs import" to create
directories in the repostiory (or indeed of using it to do anything at
all other than import code to a vendor branch in a module that's soley
to be managed as vendor branched code) is a nasty, ugly, hack, despite
the fact that it is a documented procedure.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCPRoboHack <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>  Secrets of the Weird <[EMAIL PROTECTED]>


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Fuzziness on cvs import & empty directories

[Jan Stap]

Hello people,

I'm trying to figure out how to import a set of empty directories into
a CVS project. I must say I use a rather old CVS version on the client
side (1.11.1p1, Debian Woody current); on the server side it is either
also 1.11.1p1 (local repository) or 1.11.5-FreeBSD (remote one, on a
FreeBSD 4.10-STABLE system).

If I do a "cvs -f import ..." towards the local repo, the empty
directories are imported just fine; towards the remote one, they are
skipped. I don't find any CVS admin file settings on this topic, and
no release note remarks on any behavior change in this respect 1.11.1
-> 1.11.5, so I'm puzzled. The CVS manual web page at

https://www.cvshome.org/docs/manual/cvs-1.11.3/cvs_3.html#SEC42

(also said to be valid for 1.11.5 at that spot) clearly presents
importing an empty directory set as an easy way of starting a project,
so that suggests this should work. Of course I can just do a "cvs add"
for each directory, but I'm the kind that wants to know why things
happen :-). Please post any answers back to this newsgroup. Help is
greatly appreciated!

Thanks,

Jan Stap
Eindhoven
The Netherlands
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Fuzziness on cvs import & empty directories

[Jan Stap]

Hello people,

I'm trying to figure out how to import a set of empty directories into
a CVS project. I must say I use a rather old CVS version on the client
side (1.11.1p1, Debian Woody current); on the server side it is either
also 1.11.1p1 (local repository) or 1.11.5-FreeBSD (remote one, on a
FreeBSD 4.10-STABLE system).

If I do a "cvs -f import ..." towards the local repo, the empty
directories are imported just fine; towards the remote one, they are
skipped. I don't find any CVS admin file settings on this topic, and
no release note remarks on any behavior change in this respect 1.11.1
-> 1.11.5, so I'm puzzled. The CVS manual web page at

https://www.cvshome.org/docs/manual/cvs-1.11.3/cvs_3.html#SEC42

(also said to be valid for 1.11.5 at that spot) clearly presents
importing an empty directory set as an easy way of starting a project,
so that suggests this should work. Of course I can just do a "cvs add"
for each directory, but I'm the kind that wants to know why things
happen :-). Please post any answers back to this newsgroup. Help is
greatly appreciated!

Thanks,

Jan Stap
Eindhoven
The Netherlands
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: How make cvs import

[Pierre Asselin]

pierre <[EMAIL PROTECTED]> wrote:
> Hi I want to use CVS for my project, olso I make and cvs init an cvs 
> import  for the first init.
> My problem is that I must be root for make a checkout, and all the files 
> are owned root. I must change the owner for edit them.
> How make and cvs import in not administrateur login ?

Hmmm, "root" sounds like Unix and "administrateur" sounds like
Windows...  Assuming a Unix-oid box below.

You must have done the init and the import as root.  If you have
only one normal user, just change the ownership of your $CVSROOT
tree to him, recursively.  If you have many users, create a "cvs"
group and put all your users in that group;  for symmetry, create
also a *user* "cvs" and put him in the cvs group;  change the
ownership of all *directories* in the $CVSROOT tree to user cvs,
group cvs, and change the *directory* permissions to 02775 (owner
rwx, group rwx, other r-x and setgid).

The file permissions are probably 0444 and can stay that way.  It's
the directory permissions that matter most.

-- 
pa at panix dot com
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

How make cvs import

[pierre]

Hi I want to use CVS for my project, olso I make and cvs init an cvs 
import  for the first init.
My problem is that I must be root for make a checkout, and all the files 
are owned root. I must change the owner for edit them.
How make and cvs import in not administrateur login ?

Thank
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: ***glaring*** flaw in cvs import?

[Larry Jones]

Robert P. J. Day writes:
> 
> do i understand it correctly that there is 
> no way to configure cvs to ignore some *file* patterns but not the 
> same *directory* patterns?

Yes.

> if that's true, that's definitely one of 
> the worst examples of software design i've seen in lots of years.

That's because it hasn't been changed in lots of years (because it's
just not that big a problem).  Feel free to submit patches!

-Larry Jones

Any game without push-ups, hits, burns or noogies is a sissy game. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

RE: ***glaring*** flaw in cvs import?

[Jim.Hyslop]

Robert P. J. Day wrote:
> that's useful to know, but it's still appalling that the default 
> ignore list contains "core", which causes cvs to gleefully toss even 
> directories named "core".  do i understand it correctly that there is 
> no way to configure cvs to ignore some *file* patterns but not the 
> same *directory* patterns?  if that's true, that's definitely one of 
> the worst examples of software design i've seen in lots of years.
> 
> lord, you could use that in a programming class as a golden 
> example of 
> things not to do.  i'm starting to understand why so many of my 
> colleagues won't touch cvs with a barge pole.
Hmmm... do you expect a reasonable response with an attitude like that? I
hope not.

Maybe when you've had a chance to cool down, and think about the history of
CVS, we may be able to continue this conversation.

-- 
Jim Hyslop
Senior Software Designer
Leitch Technology International Inc. (http://www.leitch.com)
Columnist, C/C++ Users Journal (http://www.cuj.com/experts)


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: ***glaring*** flaw in cvs import?

[Pierre Asselin]

Robert P. J. Day <[EMAIL PROTECTED]> wrote:

>following the instructions in "tracking third-party sources", i 
> downloaded a kernel source tree that i both want to update regularly 
> from the source, and make local changes to.

>i pulled down the tree, cleared out all CVS directories to turn it 
> into a regular directory tree, then used "cvs import" to check it into 
> my local repo.

Ok, so you checked out a tree from a public CVS server and you want
to import that locally.  You don't have to remove the CVS/
subdirectories.  See below.

>in the process of doing that import, the "cvs" command apparently 
> decided it didn't much care for the kernel source directory 
> net/bridge/core, and threw it away!  why?  because it's called "core"?

Because 'core' is in the default ignore list.  I usually reset the
ignore list to just 'CVS', like this,

cvs import -I! -ICVS  VENDOR 

and then check out a fresh sandbox somewhere else.

You can keep the original external sandbox untouched;  that way, you
can update it from the public CVS server and reimport any deltas to
your internal server.


-- 
pa at panix dot com
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

***glaring*** flaw in cvs import?

[Robert P. J. Day]

  following the instructions in "tracking third-party sources", i 
downloaded a kernel source tree that i both want to update regularly 
from the source, and make local changes to.

  i pulled down the tree, cleared out all CVS directories to turn it 
into a regular directory tree, then used "cvs import" to check it into 
my local repo.

  in the process of doing that import, the "cvs" command apparently 
decided it didn't much care for the kernel source directory 
net/bridge/core, and threw it away!  why?  because it's called "core"?

  i've verified that the directory is there in the source before the 
import, but it's not there once the import is done at the destination.
is this for real?

rday
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

RE: RES: CVS import

[Jim.Hyslop]

Conrad T. Pino wrote:
> I'm sure what you said is all true.
> 
> However the "find" command Derek demonstrated:
> 
>   find . -exec cvs add {} \;
> 
> and on which I was commenting isn't what Windows 2000 find does.

That was my point.


-- 
Jim Hyslop
Senior Software Designer
Leitch Technology International Inc. (http://www.leitch.com)
Columnist, C/C++ Users Journal (http://www.cuj.com/experts)



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RES: RES: CVS import

[Marcelo Carvalho Fernandes]

Larry,

I work with Diego and I have already explained that based on we have already
discussed here.
As we could see there exists a reason why checking out 1.1.1.1 in spite of
1.1.
For future users asking the same question, i think we could not just telling
to ignore but also explaing the reason. I think telling just to ignore could
dicourage people to make a better uderstand of CVS's "back stage".

-
Marcelo Carvalho Fernandes
Diretor de Sistemas
Smart Tech Consulting
Avenida Rio Branco 181 Sala 1005
[EMAIL PROTECTED]
www.smartech.com.br
Tel: 55 (21) 2532-6335

-Mensagem original-
De: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] nome de Larry
Jones
Enviada em: quinta-feira, 15 de abril de 2004 19:08
Para: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Assunto: Re: RES: CVS import


Diego Ribeiro de Andrade writes:
>
> The real question is... how do chekout/update a branch, but bring the
trunk
> revisoons of files that dont exist in the branch... but these files have
to
> be checked out in 1.1 revisions instead 1.1.1.1 revisions...

*WHY*?  Just ignore the revision numbers: they're for CVS, not you.

-Larry Jones

I wonder what's on TV now. -- Calvin


___
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: RES: CVS import

[Frederic Brehm]

How is this the grep command?  It doesn't support regular expressions which
is kind of the whole point of grep isn't it?
If you're lucky (!) enough to have a Windows 2K box handy, type "help 
findstr" in a DOS window. You'll see that it does support regular 
expressions. However, the way the "strings" argument is documented, I think 
that they're better described as "irregular" expressions. :-)

Fred

___
Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: RES: CVS import

[Larry Jones]

Diego Ribeiro de Andrade writes:
> 
> The real question is... how do chekout/update a branch, but bring the trunk
> revisoons of files that dont exist in the branch... but these files have to
> be checked out in 1.1 revisions instead 1.1.1.1 revisions...

*WHY*?  Just ignore the revision numbers: they're for CVS, not you.

-Larry Jones

I wonder what's on TV now. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS import

[Jorge Godoy]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thursday 15 April 2004 22:44, Derek Robert Price wrote:

> I did intend that for UNIX, not Windows.  God only knows what
> Windows would do with it.  :)

Sometimes I get the impression that even He doesn't knows what  
Windows would do with it... 

- -- 
Godoy. <[EMAIL PROTECTED]>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAf0DcEzC+baSjBiURAgLUAJ92NkKeC24Y/2BjFirFXcC7TwRDKQCgisiO
uK1IkumkZSqEttBMGqH2h/A=
=igJI
-END PGP SIGNATURE-


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: RES: CVS import

[Derek Robert Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Conrad T. Pino wrote:

>However the "find" command Derek demonstrated:
>
>find . -exec cvs add {} \;
>
>and on which I was commenting isn't what Windows 2000 find does.
>
>Can you say what Windows XP find does with Derek's command?


I did intend that for UNIX, not Windows.  God only knows what Windows
would do with it.  :)

Derek

- --
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at !
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAfzppLD1OTBfyMaQRAlsHAJkB3TpWIVMf4AXGQaUw9N3gUAHabACfWME1
vsM3PdKzXpQ3vm7GYv0kGgE=
=dEwQ
-END PGP SIGNATURE-



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: RES: CVS import

[Conrad T. Pino]

Hi Jim,

> From: Jim.Hyslop [mailto:[EMAIL PROTECTED]
>
> Conrad T. Pino wrote:
> >
> > To: Geoff Beier
> > > What version of Windows is this? The output I get from that command
> > > outside of the cygwin environment on a windows 2000 or xp box is:
> > > FIND: Parameter format not correct
> >
> > It's not native Windows, could be CygWin, MKS Tool Kit...
>
> It's native on Windows XP, at least. I have a copy in my system32 directory,
> with the following version information:
>
> Description: Find String (grep) Utility
> Company: Microsoft Corporation
> File Version: 5.1.2600.0 (xpclient.010817-1148)
> Internal name: find
> Item Name: Microsoft® Windows® Operating System
>
> As the description says, it's basically the 'grep' command.

I'm sure what you said is all true.

However the "find" command Derek demonstrated:

find . -exec cvs add {} \;

and on which I was commenting isn't what Windows 2000 find does.

Can you say what Windows XP find does with Derek's command?

Conrad



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: RES: CVS import

[Jim.Hyslop]

Carucci, Jason wrote:
> How is this the grep command?  It doesn't support regular 
> expressions which
> is kind of the whole point of grep isn't it?
I didn't say it *is* the grep command, I said it's "basically" the grep
command. In other words, it's a simplified grep. You can do a whole lot with
grep, without using regular expressions.

-- 
Jim Hyslop
Senior Software Designer
Leitch Technology International Inc. (http://www.leitch.com)
Columnist, C/C++ Users Journal (http://www.cuj.com/experts)





___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS import

[Jorge Godoy]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thursday 15 April 2004 17:42, Diego Ribeiro de Andrade wrote:
> The real question is... how do chekout/update a branch, but bring
> the trunk revisoons of files that dont exist in the branch... but
> these files have to be checked out in 1.1 revisions instead 1.1.1.1
> revisions... the best way to this really is dont create the vendor
> branch... because in ower scheema of use, we decided to create
> branchs in the main trunk rather then in another branch...

I didn't get what you want.

Could you be more "verbose"? 

As explained before, why are you worrying with the *CVS control 
numbers*? They aren't your application versions or anything else.


With regards to branches, they are branches of other branches or the 
main trunk... it doesn't matter from the tool point of view. Think of 
a tree on the street and think about the trunk and each branch, up to 
the leaves. 

There are trees where the leaves grow in the main trunk and when the 
tree is small they grow directly from the first branches... The same 
happens with your code tree.


Why is the vendor branch bothering you if when you check the code out 
and commit it your code will go to the main trunk and not to such a 
branch?

- -- 
Godoy. <[EMAIL PROTECTED]>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAfvl9EzC+baSjBiURAhttAJ9t7T0fcAjgWYq/DQarIyN+xFcs/QCeKsxt
KBkA+rGEZqHTKgmx9OfwdIo=
=8kQU
-END PGP SIGNATURE-


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: RES: CVS import

[Carucci, Jason]

How is this the grep command?  It doesn't support regular expressions which
is kind of the whole point of grep isn't it?

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jim.Hyslop
Sent: Thursday, April 15, 2004 3:34 PM
To: 'Conrad T. Pino'; Geoff Beier
Cc: [EMAIL PROTECTED]
Subject: RE: RES: CVS import


Conrad T. Pino wrote:
> To: Geoff Beier
> > What version of Windows is this? The output I get from that command
> > outside of the cygwin environment on a windows 2000 or xp box is:
> > FIND: Parameter format not correct
> 
> It's not native Windows, could be CygWin, MKS Tool Kit...
It's native on Windows XP, at least. I have a copy in my system32 directory,
with the following version information:

Description: Find String (grep) Utility
Company: Microsoft Corporation
File Version: 5.1.2600.0 (xpclient.010817-1148)
Internal name: find
Item Name: Microsoft(r) Windows(r) Operating System

As the description says, it's basically the 'grep' command.

-- 
Jim Hyslop
Senior Software Designer
Leitch Technology International Inc. (http://www.leitch.com) Columnist,
C/C++ Users Journal (http://www.cuj.com/experts)



___
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: RES: CVS import

[Diego Ribeiro de Andrade]

The real question is... how do chekout/update a branch, but bring the trunk
revisoons of files that dont exist in the branch... but these files have to
be checked out in 1.1 revisions instead 1.1.1.1 revisions... the best way to
this really is dont create the vendor branch... because in ower scheema of
use, we decided to create branchs in the main trunk rather then in another
branch...

- Original Message - 
From: "Conrad T. Pino" <[EMAIL PROTECTED]>
To: "Geoff Beier" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, April 15, 2004 5:16 PM
Subject: RE: RES: CVS import


> Hi Geoff,
>
> > Does *anyone* use the cvshome.org version of cvs on windows OUTSIDE of
> > cygwin as a matter of general practice? (AIUI, both wincvs and
> > tortoisecvs use cvsnt, and eclipse has its own cvs client, so if your
> > cvs use is one of those products the answer is no.) If so, what
> > environment do you use it in?
>
> I use CVS command line client from "cvshome.org" on Windows 2000 with
> CVS server on/from NetBSD for all my internal projects.
>
> > >   C:\foo\bar>find . -exec cvs add {} \;
> > >   'find' is not recognized as an internal or external command,
> > >   operable program or batch file.
> > >
> > What version of Windows is this? The output I get from that command
> > outside of the cygwin environment on a windows 2000 or xp box is:
> > FIND: Parameter format not correct
>
> It's not native Windows, could be CygWin, MKS Tool Kit...
>
> Best regards,
>
> Conrad
>
>
>
> ___
> Info-cvs mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/info-cvs
>


---
Esse email foi certificado pelo Software AVG Antivirus esta limpo de ameacas
digitais.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.627 / Virus Database: 402 - Release Date: 16/3/2004



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS import

[Derek Robert Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

McNamee, John wrote:

>On April 15, 2004 at 1:34 PM, Frederic Brehm wrote:
>
>>At 01:34 PM 4/15/2004, McNamee, John wrote:
>>
>>>I've never understood why cvs add
>>>doesn't have the option to work recursively when most other
>>>cvs commands do.  This issue keeps coming up on info-cvs.
>>
>>You can always submit a patch.
>
>
>I believe patches have been submitted, or at least offered,
>but were rejected.  Basically the idea was shot down.


I have to admit that the recursive add to a branch is a fairly
persuasive argument as far as I'm concerned, but even if you can get
Mark or Larry to agree, I won't have time to review any large patches
for some time.  If the change turns out to be small, it might slip
past my guard.  It would, of course, need test cases and documentation
in doc/cvs.texinfo.  See the HACKING file for more on submitting
patches to CVS.

Derek

- --
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at !
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAfvN6LD1OTBfyMaQRAtKtAKCT75S7/ND187ocqRsa2OxFiD//3ACgsrpY
wB6OYfwSfvY8enoq9JB6V+Y=
=H+Bj
-END PGP SIGNATURE-



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: RES: CVS import

[Jim.Hyslop]

Conrad T. Pino wrote:
> To: Geoff Beier
> > What version of Windows is this? The output I get from that command 
> > outside of the cygwin environment on a windows 2000 or xp box is:
> > FIND: Parameter format not correct
> 
> It's not native Windows, could be CygWin, MKS Tool Kit...
It's native on Windows XP, at least. I have a copy in my system32 directory,
with the following version information:

Description: Find String (grep) Utility
Company: Microsoft Corporation
File Version: 5.1.2600.0 (xpclient.010817-1148)
Internal name: find
Item Name: Microsoft® Windows® Operating System

As the description says, it's basically the 'grep' command.

-- 
Jim Hyslop
Senior Software Designer
Leitch Technology International Inc. (http://www.leitch.com)
Columnist, C/C++ Users Journal (http://www.cuj.com/experts)



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Which client under Windows? (was: RE: CVS import)

[Jim.Hyslop]

Geoff Beier wrote:
> Does *anyone* use the cvshome.org version of cvs on windows 
> OUTSIDE of 
> cygwin as a matter of general practice? (AIUI, both wincvs and 
> tortoisecvs use cvsnt, and eclipse has its own cvs client, so if your 
> cvs use is one of those products the answer is no.) If so, what 
> environment do you use it in?
Yep. Mostly Windows NT 4.0, with a few  Win95 machines and some
2000 and XP thrown into the mix. We use the cvshome.org command-line client,
and are in the process of rolling out SmartCVS (www.smartcvs.com) as the
GUI. SmartCVS is a stand-alone client.

We decided not to go with CVSNT for the command-line client, because we view
cvshome as the de facto standard CVS.

We have at least 100 CVS users.

-- 
Jim Hyslop
Senior Software Designer
Leitch Technology International Inc. (http://www.leitch.com)
Columnist, C/C++ Users Journal (http://www.cuj.com/experts)



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: RES: CVS import

[Conrad T. Pino]

Hi Geoff,

> Does *anyone* use the cvshome.org version of cvs on windows OUTSIDE of 
> cygwin as a matter of general practice? (AIUI, both wincvs and 
> tortoisecvs use cvsnt, and eclipse has its own cvs client, so if your 
> cvs use is one of those products the answer is no.) If so, what 
> environment do you use it in?

I use CVS command line client from "cvshome.org" on Windows 2000 with
CVS server on/from NetBSD for all my internal projects.

> >   C:\foo\bar>find . -exec cvs add {} \;
> >   'find' is not recognized as an internal or external command,
> >   operable program or batch file.
> >
> What version of Windows is this? The output I get from that command 
> outside of the cygwin environment on a windows 2000 or xp box is:
> FIND: Parameter format not correct

It's not native Windows, could be CygWin, MKS Tool Kit...

Best regards,

Conrad



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: CVS import

[McNamee, John]

On April 15, 2004 at 1:34 PM, Frederic Brehm wrote:
>At 01:34 PM 4/15/2004, McNamee, John wrote:
>>I've never understood why cvs add
>>doesn't have the option to work recursively when most other
>>cvs commands do.  This issue keeps coming up on info-cvs.
>
>You can always submit a patch.

I believe patches have been submitted, or at least offered,
but were rejected.  Basically the idea was shot down.


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: RES: CVS import

[McNamee, John]

On April 15, 2004 at 1:08 PM, Geoff Beier wrote:
>On Apr 15, 2004, at 1:34 PM, McNamee, John wrote:
>> 
>>
>> Unfortunately, the whole world doesn't run Unix...
>>
>... you're not running in the cygwin environment on Windows, 

Let's just say that cygwin is not universally admired.

>I'd suggest using cvsnt along with some other way to collect files and 
>execute commands on them. Most of the time, I advise windows users who 
>are not using cygwin to get TortoiseCVS ...

TortoiseCVS is a just GUI.

>Does *anyone* use the cvshome.org version of cvs on windows OUTSIDE of 
>cygwin as a matter of general practice?

I use the cvshome.org version of cvs on plain Win32 every day.  My whole
team does.  I also sometimes use WinCvs, but prefer the command line.

>>   C:\foo\bar>find . -exec cvs add {} \;
>>   'find' is not recognized as an internal or external command,
>>   operable program or batch file.
>>
>What version of Windows is this? The output I get from that command 
>outside of the cygwin environment on a windows 2000 or xp box is:
>FIND: Parameter format not correct

You're right, there is a find on Windows, but it's not the same as
Unix find.  I was making a rhetorical point.  There is no standard
Windows utility that does what Unix find does.

>At any rate, what benefit does adding files recursively carry over 
>using "cvs import" and ignoring the vendor branch if you don't want
>to use it?

I want to make clear that I don't care about RCS revision numbers.
I know some people who have complained about cvs import were just
upset that they saw a "weird" 1.1.1.1 revision.  I don't care.

My big problem is working on branches.  I often need to add a whole
tree worth of new files to a specific branch, and cvs import can't
do it.

Now let's step back for a minute.  There are easy workarounds for
the lack of recursive cvs add.  I wrote a Perl script to do it,
and using find on Unix isn't bad either.  The point of my flame
was that recursive add appears to be an often requested feature
that has been rejected for philosophical reasons, not technical
merit.


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: RES: CVS import

[Derek Robert Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Geoff Beier wrote:

> Does *anyone* use the cvshome.org version of cvs on windows OUTSIDE
> of cygwin as a matter of general practice? (AIUI, both wincvs and
> tortoisecvs use cvsnt, and eclipse has its own cvs client, so if
> your cvs use is one of those products the answer is no.) If so, what
> environment do you use it in?


I do, but for maintenance of CVS itself.  I'm not sure that counts.

Derek

- --
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at !
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAfuhMLD1OTBfyMaQRAjpIAJsH+vOTkk3gcnAoT2fSytgpr10KYQCgjVmM
LaJkw4UKgLMSWlDgT8wKTCw=
=Sfqo
-END PGP SIGNATURE-



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: RES: CVS import

[Frederic Brehm]

At 01:34 PM 4/15/2004, McNamee, John wrote:
I've never understood why cvs add
doesn't have the option to work recursively when most other
cvs commands do.  This issue keeps coming up on info-cvs.
You can always submit a patch.


I get the impression that there is no real technical reason,
but there is a philosophical belief that vendor branches are
a Good Thing, and everybody should use them whether they want
to or not.
Vendor branches are a Good Thing in some cases and you should use them if 
your situation is one of those cases.

CVS import is a handy way to do the recursive add if you don't mind the 
vendor branch stuff that goes along with it. If that bothers you, then 
don't use it.

Fred

___
Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: RES: CVS import

[Larry Jones]

McNamee, John writes:
> 
> I get the impression that there is no real technical reason,
> but there is a philosophical belief that vendor branches are
> a Good Thing, and everybody should use them whether they want
> to or not.

Have you ever tried to buy a newspaper without a sports section or not
subscribe to a single cable channel?  The simple fact is that it is
frequently more efficient to bundle things together.  You *get* a vendor
branch, essentially for free, when you do an import.  You don't have to
use it, and no one is trying to make you use it; feel free to complete
ignore it.  You can even delete the tags if it offends you so much.  For
that matter, you can use cvs admin to switch the default branch to the
trunk and remove the revisions on the vendor branch if you really want
to remove all traces of it.  But there's no good reason to -- just
ignore it.

-Larry Jones

Somebody's always running my life.  I never get to do what I want to do.
-- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

ENC: RES: CVS import

[Marcelo Carvalho Fernandes]

Larry,

Thanks, now it's ok for me.


Marcelo Carvalho Fernandes
Diretor de Sistemas
Smart Tech Consulting
Avenida Rio Branco 181 Sala 1005
[EMAIL PROTECTED]
www.smartech.com.br
Tel: 55 (21) 2532-6335


-Mensagem original-
De: Larry Jones [mailto:[EMAIL PROTECTED]
Enviada em: quinta-feira, 15 de abril de 2004 14:54
Para: Marcelo Carvalho Fernandes
Cc: [EMAIL PROTECTED]
Assunto: Re: RES: CVS import


Marcelo Carvalho Fernandes writes:
>
> CVS should have a feature to import without creating a vendor branch

Why?  The vendor branch is neither expensive nor intrusive, feel free to
just ignore it if you don't need it.

> The URL above tells "Note that the CVS "Main Branch" and the RCS Main
Trunk
> are not the same". What is each of them ? What is the diference ?

I think it's (mis)using "Main Branch" to mean "default branch".  As I
said before, the default branch can be either the trunk (aka, the RCS
Main Trunk) or the vendor branch.

> I still can't understand why when i firts checkout CVS gets the version
from
> vendor-branch if when i modify somenthing it ill commit to the main trunk.
> At the end things will be the same, but it should checkout the version
from
> the main trunk, shouldn't it ?

Files that have not been locally modified shouldn't exist on the trunk
at all, only on the vendor branch.  However, the RCS file format doesn't
allow a branch from nothing, so *the very first revision* is placed on
the trunk, too.  Subsequent vendor releases are *not* copied to the
trunk (which would be a waste of time and space), they only exist on the
vendor branch.  Since doing a normal checkout should get you the most
recent revision of each file, files that have not been locally modified
*have* to come from the vendor branch in the general case.

-Larry Jones

That's one of the remarkable things about life.  It's never so
bad that it can't get worse. -- Calvin




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: RES: CVS import

[Geoff Beier]

On Apr 15, 2004, at 1:34 PM, McNamee, John wrote:



Unfortunately, the whole world doesn't run Unix...

Unfortunately, OP did not identify his platform, so it seems reasonable 
to assume (since he's asking on this list) that he's either using UNIX 
or cygwin (which is the best way to run the cvshome.org version of CVS 
on windows). Both of those provide a find command that works as 
described. If you're not running in the cygwin environment on Windows, 
I'd suggest using cvsnt along with some other way to collect files and 
execute commands on them. Most of the time, I advise windows users who 
are not using cygwin to get TortoiseCVS for everyday CVS use:

http://tortoisecvs.sf.net/

It's very well documented, beautifully integrates explorer, cvsnt and 
ssh, and does contain the "add recursively" command you want.

Does *anyone* use the cvshome.org version of cvs on windows OUTSIDE of 
cygwin as a matter of general practice? (AIUI, both wincvs and 
tortoisecvs use cvsnt, and eclipse has its own cvs client, so if your 
cvs use is one of those products the answer is no.) If so, what 
environment do you use it in?

  C:\foo\bar>find . -exec cvs add {} \;
  'find' is not recognized as an internal or external command,
  operable program or batch file.
What version of Windows is this? The output I get from that command 
outside of the cygwin environment on a windows 2000 or xp box is:
FIND: Parameter format not correct

At any rate, what benefit does adding files recursively carry over 
using "cvs import" and ignoring the vendor branch if you don't want to 
use it?

Regards,

Geoff



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RES: RES: CVS import

[Marcelo Carvalho Fernandes]

Sorry, "cvs add" creates a new module ? I don't understand how i can use it
to import a new module.


--
Marcelo Carvalho Fernandes
Diretor de Sistemas
Smart Tech Consulting
Avenida Rio Branco 181 Sala 1005
[EMAIL PROTECTED]
www.smartech.com.br
Tel: 55 (21) 2532-6335











-Mensagem original-
De: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] nome de McNamee,
John
Enviada em: quinta-feira, 15 de abril de 2004 14:34
Para: [EMAIL PROTECTED]
Assunto: RE: RES: CVS import


> It does.  It's called `cvs add':
>
> $ find . -exec cvs add {} \;



Unfortunately, the whole world doesn't run Unix...

  C:\foo\bar>find . -exec cvs add {} \;
  'find' is not recognized as an internal or external command,
  operable program or batch file.

It's no big deal to get a Unix-style find utility for Windows,
but that isn't the point.  I've never understood why cvs add
doesn't have the option to work recursively when most other
cvs commands do.  This issue keeps coming up on info-cvs.
I get the impression that there is no real technical reason,
but there is a philosophical belief that vendor branches are
a Good Thing, and everybody should use them whether they want
to or not.




___
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: RES: CVS import

[Larry Jones]

Marcelo Carvalho Fernandes writes:
> 
> CVS should have a feature to import without creating a vendor branch

Why?  The vendor branch is neither expensive nor intrusive, feel free to
just ignore it if you don't need it.

> The URL above tells "Note that the CVS "Main Branch" and the RCS Main Trunk
> are not the same". What is each of them ? What is the diference ?

I think it's (mis)using "Main Branch" to mean "default branch".  As I
said before, the default branch can be either the trunk (aka, the RCS
Main Trunk) or the vendor branch.

> I still can't understand why when i firts checkout CVS gets the version from
> vendor-branch if when i modify somenthing it ill commit to the main trunk.
> At the end things will be the same, but it should checkout the version from
> the main trunk, shouldn't it ?

Files that have not been locally modified shouldn't exist on the trunk
at all, only on the vendor branch.  However, the RCS file format doesn't
allow a branch from nothing, so *the very first revision* is placed on
the trunk, too.  Subsequent vendor releases are *not* copied to the
trunk (which would be a waste of time and space), they only exist on the
vendor branch.  Since doing a normal checkout should get you the most
recent revision of each file, files that have not been locally modified
*have* to come from the vendor branch in the general case.

-Larry Jones

That's one of the remarkable things about life.  It's never so
bad that it can't get worse. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: RES: CVS import

[McNamee, John]

> It does.  It's called `cvs add':
>
> $ find . -exec cvs add {} \;



Unfortunately, the whole world doesn't run Unix...

  C:\foo\bar>find . -exec cvs add {} \;
  'find' is not recognized as an internal or external command,
  operable program or batch file.

It's no big deal to get a Unix-style find utility for Windows,
but that isn't the point.  I've never understood why cvs add
doesn't have the option to work recursively when most other
cvs commands do.  This issue keeps coming up on info-cvs.
I get the impression that there is no real technical reason,
but there is a philosophical belief that vendor branches are
a Good Thing, and everybody should use them whether they want
to or not.




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: RES: CVS import

[Derek Robert Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Marcelo Carvalho Fernandes wrote:

>CVS should have a feature to import without creating a vendor branch
so as
>not to use the commands in
>http://www.loria.fr/~molli/fom-serve/cache/160.html. Does anyone have
>already submmited that to development group ?


It does.  It's called `cvs add':

$ find . -exec cvs add {} \;

Derek

- --
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at !
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAfq/OLD1OTBfyMaQRAoJ1AJ91/0EqXqduCVq5mknBFXh3cmXlsQCgusmN
0/meQlsDZllNF2xKW9WgHZk=
=NP4b
-END PGP SIGNATURE-



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RES: CVS import

[Marcelo Carvalho Fernandes]

Godoy, Larry and Spiro,

Thanks all of you !!! Now i understand what vendor branch is for. Since I
develop my own code, i don?t need it.

CVS should have a feature to import without creating a vendor branch so as
not to use the commands in
http://www.loria.fr/~molli/fom-serve/cache/160.html. Does anyone have
already submmited that to development group ?

The URL above tells "Note that the CVS "Main Branch" and the RCS Main Trunk
are not the same". What is each of them ? What is the diference ?

It tells "See Section 4C, on Branching", but where ? Other messages tells
"See 4C.6 and 4C.15", what is that ?

I still can't understand why when i firts checkout CVS gets the version from
vendor-branch if when i modify somenthing it ill commit to the main trunk.
At the end things will be the same, but it should checkout the version from
the main trunk, shouldn't it ?


--
Marcelo Carvalho Fernandes
Diretor de Sistemas
Smart Tech Consulting
Avenida Rio Branco 181 Sala 1005
[EMAIL PROTECTED]
www.smartech.com.br
Tel: 55 (21) 2532-6335

-Mensagem original-
De: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] nome de Spiro
Trikaliotis
Enviada em: quinta-feira, 15 de abril de 2004 11:04
Para: [EMAIL PROTECTED]
Assunto: Re: CVS import


Hello Marcelo,

* On Wed, Apr 14, 2004 at 03:25:46PM -0300 Marcelo Carvalho Fernandes wrote:

>  - Is there a way to import a module without creating a branch
(verdor-tag)
> and a tag (release-tag) on this branch ?
>
>  - After running "cvs import", when i checkout with no tag/revision/date
> (that is, checkout the "main trunk") the files are in revison 1.1.1.1. I
> know that when i edit and commit one of them they will turn into 1.2. Why
> not they are in 1.1 revision when i first checkout ?

As other told you, this is intentionally.

If you really do not want this behaviour (as I do), have a look at
http://mail.gnu.org/archive/html/info-cvs/2004-03/msg00246.html

where I show my work-around to this.

Best regards,
   Spiro.

--
Spiro R. Trikaliotis  http://www.trikaliotis.net/
I'm subscribed to the mailing lists I'm posting on, so please refrain
from Cc:ing me. Thank you.


___
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: CVS import

[Spiro Trikaliotis]

Hello Marcelo,

* On Wed, Apr 14, 2004 at 03:25:46PM -0300 Marcelo Carvalho Fernandes wrote:
 
>  - Is there a way to import a module without creating a branch (verdor-tag)
> and a tag (release-tag) on this branch ?
> 
>  - After running "cvs import", when i checkout with no tag/revision/date
> (that is, checkout the "main trunk") the files are in revison 1.1.1.1. I
> know that when i edit and commit one of them they will turn into 1.2. Why
> not they are in 1.1 revision when i first checkout ?

As other told you, this is intentionally.

If you really do not want this behaviour (as I do), have a look at
http://mail.gnu.org/archive/html/info-cvs/2004-03/msg00246.html

where I show my work-around to this.

Best regards,
   Spiro.

-- 
Spiro R. Trikaliotis  http://www.trikaliotis.net/
I'm subscribed to the mailing lists I'm posting on, so please refrain
from Cc:ing me. Thank you.


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: ENC: CVS import

[Jorge Godoy]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wednesday 14 April 2004 22:29, Larry Jones wrote:
> Marcelo Carvalho Fernandes writes:
> > I was studying some graphs (CVSGraph) and could see that after
> > the "cvs import" there is also a tag called "MAIN" in the vendor
> > branch (1.1.1).
>
> Standard CVS does not create that tag.  Either you're using a
> non-standard version (such as CVSNT or a locally patched version)
> or it's an artifact of CVSGraph.

This seems to be something added by WinCVS.

I've just checked a repository where the user created some files with 
WinCVS and I created other with standard cvs on Linux. My files 
didn't have such tag but my user's files had it.

Since WinCVS uses CVSNT, it might be there the source of the 
"problem". 


- -- 
Godoy. <[EMAIL PROTECTED]>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAfgFJEzC+baSjBiURAoVRAJ0XuN5BOTr7rVGx7Nt8EuQ2e2qvxgCfXexM
Ksf87LbDOI0PYZTGzfEHCs0=
=qIl1
-END PGP SIGNATURE-


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: ENC: CVS import

[Larry Jones]

Marcelo Carvalho Fernandes writes:
> 
> I was studying some graphs (CVSGraph) and could see that after the "cvs
> import" there is also a tag called "MAIN" in the vendor branch (1.1.1).

Standard CVS does not create that tag.  Either you're using a
non-standard version (such as CVSNT or a locally patched version) or
it's an artifact of CVSGraph.

> After an edit and commit, this tag jumped to the main trunk (1). When I do a
> "cvs checkout" with just the module name (no tag/revision/date) the checkout
> is made under this "branch" MAIN ? This would explain why after the import i
> checkout 1.1.1.1 (and not 1.1) and after editing i checkout 1.2.

It's possible that that is the way CVSGraph displays the default branch.
If you do ``cvs log -Nh'' on a file, you'll see a "branch:" keyword that
indicates the default branch (if blank, the default branch is the
trunk).  When you checkout without specifying a particular revision, you
get the most recent revision on the default branch.  Newly imported
files have the default branch set to the vendor branch, locally modified
files have the default branch set to the trunk.

-Larry Jones

The authorities are trying to silence any view contrary to their own!
-- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS import

[Jorge Godoy]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wednesday 14 April 2004 15:25, Marcelo Carvalho Fernandes wrote:
> Hi !
>
> I have some questions about cvs...
>
>  - Is there a way to import a module without creating a branch
> (verdor-tag) and a tag (release-tag) on this branch ?

This is a FAQ. See /usr/share/doc/cvs-/FAQ.bz2 or the 
equivalent file in your installation.

This is Q3 on the import command part.

>  - After running "cvs import", when i checkout with no
> tag/revision/date (that is, checkout the "main trunk") the files
> are in revison 1.1.1.1. I know that when i edit and commit one of
> them they will turn into 1.2. Why not they are in 1.1 revision when
> i first checkout ?

[EMAIL PROTECTED] sty]$ cvs log g2ctech.sty
[EMAIL PROTECTED]'s password:

RCS file: /home/cvs/clientes/dataprev/sty/g2ctech.sty,v
Working file: g2ctech.sty
head: 1.1
branch: 1.1.1
locks: strict
access list:
symbolic names:
arelease: 1.1.1.1
avendor: 1.1.1
keyword substitution: kv
total revisions: 2; selected revisions: 2
description:
- 
revision 1.1
date: 2003/11/10 14:49:38;  author: juliano;  state: Exp;
branches:  1.1.1;
Initial revision
- 
revision 1.1.1.1
date: 2003/11/10 14:49:38;  author: juliano;  state: Exp;  lines: +0 
- -0
no message
=
[EMAIL PROTECTED] sty]$


Both versions are present at the logs. The checked out one is changed 
for the correct version on the first commit, as you said.



Be seeing you,
- -- 
Godoy. <[EMAIL PROTECTED]>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAfZAsEzC+baSjBiURAo9QAKCYMomZO1m5x/ddhfrSzOfLR1YVswCfXHTc
PzD0SIrB3nDX83WUNzFX07w=
=/8wH
-END PGP SIGNATURE-


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

ENC: CVS import

[Marcelo Carvalho Fernandes]

Larry,

Thank's ! I've just read that in CVS manual(Per Cederqvist et al).

I know that i don't have to worry about revision numbers. But I'd like to
have a better understand if some of my customers/students ask me.

I was studying some graphs (CVSGraph) and could see that after the "cvs
import" there is also a tag called "MAIN" in the vendor branch (1.1.1).
After an edit and commit, this tag jumped to the main trunk (1). When I do a
"cvs checkout" with just the module name (no tag/revision/date) the checkout
is made under this "branch" MAIN ? This would explain why after the import i
checkout 1.1.1.1 (and not 1.1) and after editing i checkout 1.2.

I'd like to know the reason this branch is created and if under what
circunstances i can use it ? Can you help me ?

Thanks again in advance for you help,

-
Marcelo Carvalho Fernandes
Diretor de Sistemas
Smart Tech Consulting
Avenida Rio Branco 181 Sala 1005
[EMAIL PROTECTED]
www.smartech.com.br
Tel: 55 (21) 2532-6335




-Mensagem original-
De: Larry Jones [mailto:[EMAIL PROTECTED]
Enviada em: quarta-feira, 14 de abril de 2004 16:19
Para: Marcelo Carvalho Fernandes
Cc: [EMAIL PROTECTED]
Assunto: Re: CVS import


Marcelo Carvalho Fernandes writes:
>
>  - Is there a way to import a module without creating a branch
(verdor-tag)
> and a tag (release-tag) on this branch ?

No.  Just ignore them.

>  - After running "cvs import", when i checkout with no tag/revision/date
> (that is, checkout the "main trunk") the files are in revison 1.1.1.1. I
> know that when i edit and commit one of them they will turn into 1.2. Why
> not they are in 1.1 revision when i first checkout ?

Because they've been imported and thus they're on the vendor branch.
Again, just ignore the revision numbers, they're for CVS's use, not
yours.

-Larry Jones

Hello, I'm wondering if you sell kegs of dynamite. -- Calvin




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS import

[Larry Jones]

Marcelo Carvalho Fernandes writes:
> 
>  - Is there a way to import a module without creating a branch (verdor-tag)
> and a tag (release-tag) on this branch ?

No.  Just ignore them.

>  - After running "cvs import", when i checkout with no tag/revision/date
> (that is, checkout the "main trunk") the files are in revison 1.1.1.1. I
> know that when i edit and commit one of them they will turn into 1.2. Why
> not they are in 1.1 revision when i first checkout ?

Because they've been imported and thus they're on the vendor branch. 
Again, just ignore the revision numbers, they're for CVS's use, not
yours.

-Larry Jones

Hello, I'm wondering if you sell kegs of dynamite. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

CVS import

[Marcelo Carvalho Fernandes]

Hi !

I have some questions about cvs...

 - Is there a way to import a module without creating a branch (verdor-tag)
and a tag (release-tag) on this branch ?

 - After running "cvs import", when i checkout with no tag/revision/date
(that is, checkout the "main trunk") the files are in revison 1.1.1.1. I
know that when i edit and commit one of them they will turn into 1.2. Why
not they are in 1.1 revision when i first checkout ?



--
Marcelo Carvalho Fernandes
Diretor de Sistemas
Smart Tech Consulting
Avenida Rio Branco 181 Sala 1005
[EMAIL PROTECTED]
www.smartech.com.br
Tel: 55 (21) 2532-6335









___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: RSE's cvs import patch against the current CVS source

[Mark D. Baushke]

Julien Wajsberg <[EMAIL PROTECTED]> writes:

> > > How about modifying this ?
> >
> > I believe it would be a waste of time. There is still an 'enhancement'
> > request http://ccvs.cvshome.org/issues/show_bug.cgi?id=27 to have the
> > verifymsg processed only once rather than for each directory...
> >
> > Somewhere before the call to do_verify ?
> >
> > I'd suggest that this is not a useful distraction for RSE right now.
> 
> If there is no advantage at doing that, surely it is a waste of time.
> But if it adds coherence, why don't you want to add this feature in the
> good way at the first time ?

In what way does it add coherence to modify the existing behavior and
add a new feature at the same time? I suppose that making both changes
at once may have some benefit, but the existing feature for RSE is
apparently one that works and is stable. All we are asking for is some
additional documentation and test cases rather than new development
work.

> Moreover, it could help (later) if you want to modify the code in
> order not to show an editor if commitinfo is failing, for example
> (just a thought).

I suppose you may have a point.

Right now the client/server protocol expects the log message to be
transmitted over the wire at the same time that modified files are being
copied to the server for consideration in the commit. So, the local
'editinfo' prompting for the log message occurs before any file is
transmitted so that the log message along with all possibly modified
files may be transmitted in one transaction to optimize keeping a remote
link open for the shortest period of time possible. 

This has the side-effect folks doing on-demand dialup will pay the least
amount of connect time for a single commit. It also means that the
server keeps the remote snapshot of the user's changes for as small a
period of time as possible.

If the intent is to optimize minimum input for the user, it might make
sense to be able to reject a commit without even getting around to
prompting the user into reading the log message... however, some users
take a long time to write interactive log messages and these users would
be keeping the server diskspace and network connections open which will
increase the load on the server during the time that the user is writing
a log message using their local editor. If the 'normal' condition is to
have a commit succeed, then the added load would seem to have no upside.
If the 'normal' condition is to reject commits, then your proposal may
have greater merit. I am just not certain how much the remote protocol
would need to be extended to deal with the late transmission of the log
message (I have not looked closely at that part of the protocol).

I suspect that the current method makes more sense from a network
bandwidth and server transient disk consumption point of view and any
change is going to have to try to justify that extra load and possible
connect-time expense.

Enjoy!
-- Mark


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: RSE's cvs import patch against the current CVS source

[Julien Wajsberg]

Mark D. Baushke wrote:


> Julien Wajsberg <[EMAIL PROTECTED]> writes:
>
> > I just saw that 'verifymsg' is processed before 'importinfo' with your
> > patch. I don't think it is the correct behaviour :)
>
> I suggest that you should not depend on the ordering of the verifymsg as
> compared to the importinfo or commitinfo.

I don't depend of the order. It just happens in our setup that verifymsg
takes longer than other hooks.

> In client/server mode, verifymsg is processed first. In local mode,
> verifymsg is usually called after the commitinfo has been called.

My understanding was that commitinfo/taginfo always occurs before
verifymsg. It seems I was wrong...

> It is just as reasonable to reject a commit due to a bad log message as
> it is to reject it because a file is being committed does not pass some
> commitinfo check.

Yes I agree with that.

> > How about modifying this ?
>
> I believe it would be a waste of time. There is still an 'enhancement'
> request http://ccvs.cvshome.org/issues/show_bug.cgi?id=27 to have the
> verifymsg processed only once rather than for each directory...
>
> Somewhere before the call to do_verify ?
>
> I'd suggest that this is not a useful distraction for RSE right now.

If there is no advantage at doing that, surely it is a waste of time.
But if it adds coherence, why don't you want to add this feature in the
good way at the first time ?

Moreover, it could help (later) if you want to modify the code in order not
to show an editor if
commitinfo is failing, for example (just a thought).

--
Julien
PS: sorry Mark, I hit the wrong reply button at first...



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: RSE's cvs import patch against the current CVS source

[Mark D. Baushke]

Julien Wajsberg <[EMAIL PROTECTED]> writes:

> I just saw that 'verifymsg' is processed before 'importinfo' with your
> patch. I don't think it is the correct behaviour :)

I suggest that you should not depend on the ordering of the verifymsg as
compared to the importinfo or commitinfo.

In client/server mode, verifymsg is processed first. In local mode,
verifymsg is usually called after the commitinfo has been called.

It is just as reasonable to reject a commit due to a bad log message as
it is to reject it because a file is being committed does not pass some
commitinfo check.
 
> How about modifying this ?

I believe it would be a waste of time. There is still an 'enhancement'
request http://ccvs.cvshome.org/issues/show_bug.cgi?id=27 to have the
verifymsg processed only once rather than for each directory...

> Somewhere before the call to do_verify ?

I'd suggest that this is not a useful distraction for RSE right now.

Thanks,
-- Mark


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: RSE's cvs import patch against the current CVS source

[Julien Wajsberg]

I just saw that 'verifymsg' is processed before 'importinfo' with your
patch.
I don't think it is the correct behaviour :)

How about modifying this ?
Somewhere before the call to do_verify ?

--
Julien Wajsberg

--
Answer to Ralf S. Engelschall <[EMAIL PROTECTED]> :
--


On Tue, Jul 29, 2003, Mark D. Baushke wrote:

> > Any possibility to make it a feature of the mainstream CVS?
> [...]
> Also, the patch should not be conditional on the macros RSE_PATCHES or
> RSE_PATCH_IMPORTINFO, so those parts of the patch need to be removed.
> [...]

Sure, the #ifdef/#endif wrappers are there just for two reason: to allow
me to exactly identify what code changes belong to which parts of my
larger patch set and to allow me to selectively activate/deactivate
some parts of it. For a possible inclusion into the mainstream CVS
source these would be gone, of course. As already mentioned to Mark
in a private mail, I'll try to find some time over the next weeks and
work-off my patch set by adding sanity.sh and documentation changes and
moving it up to the latest CVS HEAD version. I also will separate the
large patch set into individual smaller ones (for easier review by the
CVS developer team).
   Ralf S. Engelschall
   [EMAIL PROTECTED]
   www.engelschall.com



___
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: Feature Request: admin files for "cvs import" and "cvs add"

[Greg A. Woods]

[ On Wednesday, July 30, 2003 at 09:39:35 (+0800), Wu Yongwei wrote: ]
> Subject: Re: Feature Request: admin files for "cvs import" and "cvs add"
>
> Don't you like CVS to be more secure?

No, actually I don't, at least not in the way you're suggesting.

I want CVS to be a good source-code change tracking tool, and nothing
more.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCPRoboHack <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>  Secrets of the Weird <[EMAIL PROTECTED]>


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Feature Request: admin files for "cvs import" and "cvs add"

[Wu Yongwei]

Greg A. Woods wrote:
> If you're worried about that kind of threat then you have far bigger
> problems than you think.
>
> CVS is not a security tool.

No, it is not.  Yet.  But I love CVS and love to have a secure CVS.  (BTW,
my employer is a network security vendor :-).)

Don't you like CVS to be more secure?

Best regards,

Wu Yongwei



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Feature Request: admin files for "cvs import" and "cvs add"

[Greg A. Woods]

[ On Tuesday, July 29, 2003 at 16:44:03 (+0800), Wu Yongwei wrote: ]
> Subject: Re: Feature Request: admin files for "cvs import" and "cvs add"
>
> I don't think so.  Check yourself on the server, and you will find that the
> directories are really added to the repository.

I know exactly what happens.

However what you're seeing is the on-time creation of internal meta
information that's almost completely inconsequential to the bigger
picture.

CVS does not manage directories only the files contained within them.

However CVS does require that an empty directory exist in the repository
before it will agree to commit a new file to that directory.


>  At least theoretically a
> user can add directories recursively this way and cause the free disk space
> to become zero.

If you're worried about that kind of threat then you have far bigger
problems than you think.

CVS is not a security tool.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCPRoboHack <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>  Secrets of the Weird <[EMAIL PROTECTED]>


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: RSE's cvs import patch against the current CVS source

[Ralf S. Engelschall]

On Tue, Jul 29, 2003, Mark D. Baushke wrote:

> > Any possibility to make it a feature of the mainstream CVS?
> [...]
> Also, the patch should not be conditional on the macros RSE_PATCHES or
> RSE_PATCH_IMPORTINFO, so those parts of the patch need to be removed.
> [...]

Sure, the #ifdef/#endif wrappers are there just for two reason: to allow
me to exactly identify what code changes belong to which parts of my
larger patch set and to allow me to selectively activate/deactivate
some parts of it. For a possible inclusion into the mainstream CVS
source these would be gone, of course. As already mentioned to Mark
in a private mail, I'll try to find some time over the next weeks and
work-off my patch set by adding sanity.sh and documentation changes and
moving it up to the latest CVS HEAD version. I also will separate the
large patch set into individual smaller ones (for easier review by the
CVS developer team).
   Ralf S. Engelschall
   [EMAIL PROTECTED]
   www.engelschall.com



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Feature Request: admin files for "cvs import" and "cvs add"

[Wu Yongwei]

I agree that it is not a serious issue, and I agree that addinfo is ugly.
How about triggering the script in commitinfo (regarding the directory
adding opeation as a hidden committing opeation)?  I feel that is more
consistent (adding files will trigger commitinfo).

Best regards,

Wu Yongwei

--- Original Message from Mark D. Baushke ---

Wu Yongwei <[EMAIL PROTECTED]> writes:

> I don't think so.  Check yourself on the server, and you will find that
the
> directories are really added to the repository.  At least theoretically a
> user can add directories recursively this way and cause the free disk
space
> to become zero.

So, is this a public repository somewhere that you expect someone to
keep pounding your server with 'cvs add' commands? Or, is it a corporate
cvs repository where your employer could terminate someone that does
something that foolish?

If you trust someone to have access to your repository, then they can do
a lot worse things than create some empty directories in your
repository.

If you are really desperate, you could have the loginfo script police
the 'cvs add ' operation and remove any directory that is not
really allowed by your policy to be created.

I just do not see a real justification yet for an 'addinfo' script for
the 'cvs add ' command. Directories are not really controlled
entities in cvs and it makes me uncomfortable to have a special-purpose
script to deal with their creation.

   -- Mark



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Feature Request: admin files for "cvs import" and "cvsadd"

[Mark D. Baushke]

Wu Yongwei <[EMAIL PROTECTED]> writes:

> I don't think so.  Check yourself on the server, and you will find that the
> directories are really added to the repository.  At least theoretically a
> user can add directories recursively this way and cause the free disk space
> to become zero.

So, is this a public repository somewhere that you expect someone to
keep pounding your server with 'cvs add' commands? Or, is it a corporate
cvs repository where your employer could terminate someone that does
something that foolish?

If you trust someone to have access to your repository, then they can do
a lot worse things than create some empty directories in your
repository.

If you are really desperate, you could have the loginfo script police
the 'cvs add ' operation and remove any directory that is not
really allowed by your policy to be created.

I just do not see a real justification yet for an 'addinfo' script for
the 'cvs add ' command. Directories are not really controlled
entities in cvs and it makes me uncomfortable to have a special-purpose
script to deal with their creation.

-- Mark


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Feature Request: admin files for "cvs import" and "cvs add"

[Wu Yongwei]

I don't think so.  Check yourself on the server, and you will find that the
directories are really added to the repository.  At least theoretically a
user can add directories recursively this way and cause the free disk space
to become zero.

Best regards,

Wu Yongwei

--- Original Message from Greg A. Woods ---

> I doubt it.  When I type "cvs add test" and test is a directory, the test
> directory (as well as a log message) will be generated on the server.  The
> only problem is that the script in commitinfo is not triggered.  But I see
> it really a hidden commit operation.

No, what you're seeing is a side-effect of the way CVS works under the
hood.  In reality no directory is created in the managed module because
CVS does not manage directories -- it manages only changes to files that
are contained within directories.

The effect of "cvs add new-directory" is simply an artifact of the
implementation and provided you use CVS in the recommended manner you
can treat this an an abberation which is necessary in order to use CVS
but which is not a true change that needs to be managed from any "*info"
script.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: RSE's cvs import patch against the current CVS source

[Mark D. Baushke]

Wu Yongwei <[EMAIL PROTECTED]> writes:

> Any possibility to make it a feature of the mainstream CVS?

Patches against the cvs trunk (1.12.1.1) that include sanity.sh test
cases to exercise the new feature will be considered. 

Only bug fixes are going into the cvs 1.11.x branch, so this feature
will not go there.

Also, the patch should not be conditional on the macros RSE_PATCHES or
RSE_PATCH_IMPORTINFO, so those parts of the patch need to be removed.

Enjoy!
-- Mark


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RSE's cvs import patch against the current CVS source

[Wu Yongwei]

Any possibility to make it a feature of the mainstream CVS?

Best regards,

Wu Yongwei


cvs-import.diff
Description: Binary data
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Feature Request: admin files for "cvs import" and "cvs add"

[Greg A. Woods]

[ On Tuesday, July 29, 2003 at 10:05:46 (+0800), Wu Yongwei wrote: ]
> Subject: Re: Feature Request: admin files for "cvs import" and "cvs add"
>
> I doubt it.  When I type "cvs add test" and test is a directory, the test
> directory (as well as a log message) will be generated on the server.  The
> only problem is that the script in commitinfo is not triggered.  But I see
> it really a hidden commit operation.

No, what you're seeing is a side-effect of the way CVS works under the
hood.  In reality no directory is created in the managed module because
CVS does not manage directories -- it manages only changes to files that
are contained within directories.

The effect of "cvs add new-directory" is simply an artifact of the
implementation and provided you use CVS in the recommended manner you
can treat this an an abberation which is necessary in order to use CVS
but which is not a true change that needs to be managed from any "*info"
script.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCPRoboHack <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>  Secrets of the Weird <[EMAIL PROTECTED]>


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Feature Request: admin files for "cvs import" and "cvs add"

[Mark D. Baushke]

Wu Yongwei <[EMAIL PROTECTED]> writes:

> Now I wonder, is it possible that this feature could be incorporated
> into the mainstream cvs source?

Yes, it is possible.

Write a patch against the top-of-tree cvs sources and include sanity.sh
test(s) for the new feature as well as a ChangeLog entry. Submit the
patch to [EMAIL PROTECTED] and we will see what happens. :-)

I am in favor of the admininfo and importinfo features, but it would be
best if they were separate patches.

I am less sure that the case has been made to change how "cvs add "
works, but if you write the patch then we can see if it looks like the
right approach.

Enjoy!
-- Mark


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Feature Request: admin files for "cvs import" and "cvs add"

[Wu Yongwei]

Ralf S. Engelschall wrote:
> Admin/info hooks for "cvs admin" and "cvs import" you can find in my
> optional "RSE-patches" contained in the OpenPKG package for CVS:
> http://cvs.openpkg.org/openpkg-src/cvs/cvs.patch.rse

So many thanks, Ralf!  It works, and it gives me a good example how to hack
the CVS source :-)!  Thanks go to Julien too.  You saved me the trouble to
separate the patch.

> Controlling "cvs add" is currently not supported, but this usually isn't
> a big deal. I just run a little cronjob once per day to remove empty
> dirs from our CVS repositories...

Agreed.  But I'll have a look later whether it is easy to make a change.


Now I wonder, is it possible that this feature could be incorporated into
the mainstream cvs source?  I think it a good feature.  Locally I have
already the patch against the current cvs source on the cvs server.  And I
have tested with a modified the cvs_acls script to make it prevent
unauthorized import operation.  It seems OK.

Best regards,

Wu Yongwei



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Feature Request: admin files for "cvs import" and "cvs add"

[Wu Yongwei]

Alexandre Augusto Drummond Barroso wrote:
> I think the discution is limited to what can be done about the import
> issue, because cvs doesn't deal with the concept of "adding directories"

A user could add a directory without triggering the script in commitinfo,
which I regard as a potential security hole.  No matter what the concept is
in CVS.

> or "removing directories" directly. AFAIK, what it really does is "remove
> all files from certain directory" to remove a directory or "add files that
> have a common path witch doesn't exist before" to add a directory.

I doubt it.  When I type "cvs add test" and test is a directory, the test
directory (as well as a log message) will be generated on the server.  The
only problem is that the script in commitinfo is not triggered.  But I see
it really a hidden commit operation.

>
> Zandall.

However, I agree that this issue is not as important as the "import" issue.
In most circumstances it is harmless and recoverable.  But why not prevent
it beforehand?  In some cases you cannot expect that every developer is
smart and knows how to do things correctly.

Best regards,

Wu Yongwei



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Feature Request: admin files for "cvs import" and "cvsadd "

[Julien Wajsberg]

Ralf,

Thanks for your patch.

here is only the 'importinfo' part of your patch, backported to CVS 1.11.5
(I hope it will work on 1.11.6 too).


 (See attached file: cvs-importinfo-2.patch)

It builds succesfully, and I will now try to use it ;)

--
Julien Wajsberg


-
Answer to Ralf S. Engelschall <[EMAIL PROTECTED]>:




On Tue, Jul 22, 2003, Wu Yongwei wrote:

> My previous post titled "cvs_acls and cvs import" has got no reply so
far,
> and I suppose I should regard it as no one knows of an answer except
> modifying source.
>
> Thus I request that administrative files for "cvs import" and "cvs add
> " be added to cvs to control these operations. Not being a cvs guru,
I
> just want to give my opinions, and hope that some veteran here could give
> helpful suggestions.
>
> One way is just to add new administrative files, like "importinfo" and
> "adddirinfo".  If files are too many, maybe some could be merged, say, we
> could use "commitinfo" to check the "add " operation.
>
> Opinions?
>
> (When we can agree on how to change, I can have a try to modify the
source,
> if no one else is willing to do it.  But before that I want to hear
others'
> opinions on what to do and get advice on how.  I am not familiar with the
> cvs source.)

Admin/info hooks for "cvs admin" and "cvs import" you can find in my
optional "RSE-patches" contained in the OpenPKG package for CVS:
http://cvs.openpkg.org/openpkg-src/cvs/cvs.patch.rse

Controlling "cvs add" is currently not supported, but this usually isn't
a big deal. I just run a little cronjob once per day to remove empty
dirs from our CVS repositories...

   Ralf S. Engelschall
   [EMAIL PROTECTED]
   www.engelschall.com



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs




cvs-importinfo-2.patch
Description: Binary data
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Feature Request: admin files for "cvs import" and "cvs add"

[Ralf S. Engelschall]

On Tue, Jul 22, 2003, Wu Yongwei wrote:

> My previous post titled "cvs_acls and cvs import" has got no reply so far,
> and I suppose I should regard it as no one knows of an answer except
> modifying source.
>
> Thus I request that administrative files for "cvs import" and "cvs add
> " be added to cvs to control these operations. Not being a cvs guru, I
> just want to give my opinions, and hope that some veteran here could give
> helpful suggestions.
>
> One way is just to add new administrative files, like "importinfo" and
> "adddirinfo".  If files are too many, maybe some could be merged, say, we
> could use "commitinfo" to check the "add " operation.
>
> Opinions?
>
> (When we can agree on how to change, I can have a try to modify the source,
> if no one else is willing to do it.  But before that I want to hear others'
> opinions on what to do and get advice on how.  I am not familiar with the
> cvs source.)

Admin/info hooks for "cvs admin" and "cvs import" you can find in my
optional "RSE-patches" contained in the OpenPKG package for CVS:
http://cvs.openpkg.org/openpkg-src/cvs/cvs.patch.rse

Controlling "cvs add" is currently not supported, but this usually isn't
a big deal. I just run a little cronjob once per day to remove empty
dirs from our CVS repositories...

   Ralf S. Engelschall
   [EMAIL PROTECTED]
   www.engelschall.com



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Feature Request: admin files for "cvs import" and "cvs add"

[Alexandre Augusto Drummond Barroso]

I think the discution is limited to what can be done about the import issue, because 
cvs doesn't deal with the concept of "adding directories" or "removing directories" 
directly. AFAIK, what it really does is "remove all files from certain directory" to 
remove a directory or "add files that have a common path witch doesn't exist before" 
to add a directory. 

Zandall.

> -Original Message-
> From: Julien Wajsberg [mailto:[EMAIL PROTECTED]
> Sent: Friday, July 25, 2003 7:56 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Feature Request: admin files for "cvs import" and "cvs
> add"
> 
> 
> 
> 
> I think it is an important issue, and I don't understand why a CVS
> developer didn't
> give an advice about this yet...
> 
> --
> Julien Wajsberg
> 
> 
> 
> 
> My previous post titled "cvs_acls and cvs import" has got no 
> reply so far,
> and I suppose I should regard it as no one knows of an answer except
> modifying source.
> 
> Thus I request that administrative files for "cvs import" and "cvs add
> " be added to cvs to control these operations. Not being 
> a cvs guru, I
> just want to give my opinions, and hope that some veteran 
> here could give
> helpful suggestions.
> 
> One way is just to add new administrative files, like "importinfo" and
> "adddirinfo".  If files are too many, maybe some could be 
> merged, say, we
> could use "commitinfo" to check the "add " operation.
> 
> Opinions?
> 
> (When we can agree on how to change, I can have a try to 
> modify the source,
> if no one else is willing to do it.  But before that I want 
> to hear others'
> opinions on what to do and get advice on how.  I am not 
> familiar with the
> cvs source.)
> 
> Best regards,
> 
> Wu Yongwei
> 
> 
> 
> ___
> 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: Feature Request: admin files for "cvs import" and "cvs add"

[Julien Wajsberg]

I was just answering to another mail.

You can find my first mail about this issue here :
http://mail.gnu.org/archive/html/info-cvs/2003-07/msg00083.html

the first mail of Mr Wu Yongwei here :
http://mail.gnu.org/archive/html/info-cvs/2003-07/msg00111.html

and his second mail here :
http://mail.gnu.org/archive/html/info-cvs/2003-07/msg00144.html

Hope this helps you.

--
Julien Wajsberg

PS: again, sorry for Lotus Notes' bad layout...

--
Marc Priest <[EMAIL PROTECTED]> wrote :




Julien,

I can't seem to find your earlier posting in the archives so I don't know
what you are talking about.  Can you please provide some more information
about this?

Thanks,
Mark

- Original Message -
From: "Julien Wajsberg" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 25, 2003 6:56 AM
Subject: Re: Feature Request: admin files for "cvs import" and "cvs
add"


>
>
> I think it is an important issue, and I don't understand why a CVS
> developer didn't
> give an advice about this yet...
>
> --
> Julien Wajsberg
>
>
>
>
> My previous post titled "cvs_acls and cvs import" has got no reply so
far,
> and I suppose I should regard it as no one knows of an answer except
> modifying source.
>
> Thus I request that administrative files for "cvs import" and "cvs add
> " be added to cvs to control these operations. Not being a cvs guru,
I
> just want to give my opinions, and hope that some veteran here could give
> helpful suggestions.
>
> One way is just to add new administrative files, like "importinfo" and
> "adddirinfo".  If files are too many, maybe some could be merged, say, we
> could use "commitinfo" to check the "add " operation.
>
> Opinions?
>
> (When we can agree on how to change, I can have a try to modify the
source,
> if no one else is willing to do it.  But before that I want to hear
others'
> opinions on what to do and get advice on how.  I am not familiar with the
> cvs source.)
>
> Best regards,
>
> Wu Yongwei
>
>
>
> ___
> 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: Feature Request: admin files for "cvs import" and "cvs add"

[Julien Wajsberg]

I think it is an important issue, and I don't understand why a CVS
developer didn't
give an advice about this yet...

--
Julien Wajsberg




My previous post titled "cvs_acls and cvs import" has got no reply so far,
and I suppose I should regard it as no one knows of an answer except
modifying source.

Thus I request that administrative files for "cvs import" and "cvs add
" be added to cvs to control these operations. Not being a cvs guru, I
just want to give my opinions, and hope that some veteran here could give
helpful suggestions.

One way is just to add new administrative files, like "importinfo" and
"adddirinfo".  If files are too many, maybe some could be merged, say, we
could use "commitinfo" to check the "add " operation.

Opinions?

(When we can agree on how to change, I can have a try to modify the source,
if no one else is willing to do it.  But before that I want to hear others'
opinions on what to do and get advice on how.  I am not familiar with the
cvs source.)

Best regards,

Wu Yongwei



___
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

Feature Request: admin files for "cvs import" and "cvs add "

[Wu Yongwei]

My previous post titled "cvs_acls and cvs import" has got no reply so far,
and I suppose I should regard it as no one knows of an answer except
modifying source.

Thus I request that administrative files for "cvs import" and "cvs add
" be added to cvs to control these operations. Not being a cvs guru, I
just want to give my opinions, and hope that some veteran here could give
helpful suggestions.

One way is just to add new administrative files, like "importinfo" and
"adddirinfo".  If files are too many, maybe some could be merged, say, we
could use "commitinfo" to check the "add " operation.

Opinions?

(When we can agree on how to change, I can have a try to modify the source,
if no one else is willing to do it.  But before that I want to hear others'
opinions on what to do and get advice on how.  I am not familiar with the
cvs source.)

Best regards,

Wu Yongwei



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

cvs_acls and cvs import

[Wu Yongwei]

Generally I am quite satisfied with the cvs_acls.pl script.  However, in
testing I found that it was possible that a user used "cvs import" to
add/modify files that he was not supposed to touch.  It was because the
"import" operation did not trigger the scripts in commitinfo at all.  I do
not know anywhere to put scripts to stop such imports.  Thus currently
anybody not forbidden by the "readers" file can modify any file if he knows
this (if the file system does not restrict him).

Anyway to limit the import operation?

Best regards,

Wu Yongwei



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: FW: cvs import & checkout -D date_spec

[Larry Jones]

Chen, Susie writes:
> 
>   [1st import]
>   cvs import -ko -kb -I!   

There's no point in specifying -k more than once, only the last one is
effective.

>   cvs rtag  

rtag without -r is almost always a mistake -- you have no idea what
revisions you're actually tagging.  And without -b you're creating a
revision tag, not a branch tag.

>   cvs checkout -D  -r  
> 
> The rtag command makes the import available only to the branch.

I have no idea what that is supposed to mean.  import generally makes
the import available on the trunk except for files that have been
locally modified.  If there are any locally modified files, you need to
do a merge to merge the vendor changes into the local changes on the
trunk.

Perhaps it would help if you explained exactly what it is that you're
trying to do.

And it really would help to see the *exact* commands you're using, or at
least exactly what you're using for .

-Larry Jones

I'm a genius. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: FW: cvs import & checkout -D date_spec

[Chen, Susie]

Actually I posted the question for a colleague.  Here is the sequence of
commands he used:

[1st import]
cvs import -ko -kb -I!   
cvs rtag  
cvs checkout -D  -r  

The rtag command makes the import available only to the branch. The check
outs are fine at this point.

[2nd import]
cvs import -ko -kb -I!   
cvs rtag -d  
cvs rtag  
cvs checkout -D  -r  

The rtag -d and the subsequent rtag commands are necessary so that checkout
picks out the latest i.e. the 2nd import. And 'cvs checkout' works with
either -D or -r but not together after the 2nd import. (OK, the -D option on
its own is rather pointless as far as we're concerned.)

Hope this is clear.

Thanks
sc

]-Original Message-
]From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
]Sent: Thursday, May 29, 2003 2:55 PM
]To: [EMAIL PROTECTED]
]Cc: [EMAIL PROTECTED]
]Subject: Re: FW: cvs import & checkout -D date_spec
]
]
]Chen, Susie writes:
]> 
]> It does not seem time zone is the issue here, unless I 
]> misunderstood something. Both the server and the client are in 
]> the same time zone.  As I said, the same CVS checkout command,
]> 
]>  cvs checkout -D  -r  
]> 
]> used to work with the 1st import. It does not work after the 
]> 2nd import. And because the import was for a branch, I have to 
]> re-tag so that a check out picks up the latest (i.e. the 2nd 
]> import). Indeed, a checkout without the -D works fine and 
]> picks up the latest. And checkout with -D and without -r also 
]> works fine. There seems to be some conflict between -D & -r. 
]> But what's interesting is that checkout with -D and -r works 
]> fine before the 2nd import!
]
]It would be helpful if you showed us the exact commands you used, the
]results you got, and exactly how that differs from what you expected.
]Also, what versions of CVS you are using ("cvs version" will show both
]the client and server versions).  "Doesn't work" is a bit nebulous.
]
]-Larry Jones
]
]Pitiful.  Just pitiful. -- Calvin
]


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: FW: cvs import & checkout -D date_spec

[Larry Jones]

Chen, Susie writes:
> 
> It does not seem time zone is the issue here, unless I 
> misunderstood something. Both the server and the client are in 
> the same time zone.  As I said, the same CVS checkout command,
> 
>   cvs checkout -D  -r  
> 
> used to work with the 1st import. It does not work after the 
> 2nd import. And because the import was for a branch, I have to 
> re-tag so that a check out picks up the latest (i.e. the 2nd 
> import). Indeed, a checkout without the -D works fine and 
> picks up the latest. And checkout with -D and without -r also 
> works fine. There seems to be some conflict between -D & -r. 
> But what's interesting is that checkout with -D and -r works 
> fine before the 2nd import!

It would be helpful if you showed us the exact commands you used, the
results you got, and exactly how that differs from what you expected.
Also, what versions of CVS you are using ("cvs version" will show both
the client and server versions).  "Doesn't work" is a bit nebulous.

-Larry Jones

Pitiful.  Just pitiful. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

FW: cvs import & checkout -D date_spec

[Chen, Susie]

It does not seem time zone is the issue here, unless I 
misunderstood something. Both the server and the client are in 
the same time zone. As I said, the same CVS checkout command,

cvs checkout -D  -r  

used to work with the 1st import. It does not work after the 
2nd import. And because the import was for a branch, I have to 
re-tag so that a check out picks up the latest (i.e. the 2nd 
import). Indeed, a checkout without the -D works fine and 
picks up the latest. And checkout with -D and without -r also 
works fine. There seems to be some conflict between -D & -r. 
But what's interesting is that checkout with -D and -r works 
fine before the 2nd import!

sc

]]-Original Message-
]]From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
]]Sent: Thursday, May 29, 2003 11:52 AM
]]To: [EMAIL PROTECTED]
]]Cc: [EMAIL PROTECTED]
]]Subject: Re: cvs import & checkout -D date_spec
]]
]]
]]Chen, Susie writes:
]]> 
]]> After a 2nd import, checkout -D date_spec did not checked 
]]out. The same
]]> checkout command works fine for the 1st import. Does anyone 
]]has similar
]]> experiences to share? FYI, the import was for binaries 
]]libraries. And yes,
]]> -I! was used in the import, so there is no question if the 
]]binaries were in
]]> the repository. And checkout without the -D option works 
]]fine as well.
]]
]]Are you sure you're specifying the date correctly?  CVS displays dates
]]in UTC but dates in commands that don't include a timezone (like UTC)
]]are interpreted as local time.
]]
]]-Larry Jones
]]
]]It works on the same principle as electroshock therapy. -- Calvin
]]
]


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cvs import & checkout -D date_spec

[Larry Jones]

Chen, Susie writes:
> 
> After a 2nd import, checkout -D date_spec did not checked out. The same
> checkout command works fine for the 1st import. Does anyone has similar
> experiences to share? FYI, the import was for binaries libraries. And yes,
> -I! was used in the import, so there is no question if the binaries were in
> the repository. And checkout without the -D option works fine as well.

Are you sure you're specifying the date correctly?  CVS displays dates
in UTC but dates in commands that don't include a timezone (like UTC)
are interpreted as local time.

-Larry Jones

It works on the same principle as electroshock therapy. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

cvs import & checkout -D date_spec

[Chen, Susie]

After a 2nd import, checkout -D date_spec did not checked out. The same
checkout command works fine for the 1st import. Does anyone has similar
experiences to share? FYI, the import was for binaries libraries. And yes,
-I! was used in the import, so there is no question if the binaries were in
the repository. And checkout without the -D option works fine as well.

sc


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cvs import -I ! hangs

[Øyvind A. Holm]

On 2003-05-27 15:50-0400 [EMAIL PROTECTED] wrote:

> cd CVS/ProjectA
> cvs -m " " -I ! ProjectA ProjectA start
>
> and it hangs
>
> Any ideas?

You need to escape the exclamation mark, it is interpreted by the shell.
Change it to:

cvs -m " " -I \! ProjectA ProjectA start

Regards,
Øyvind
---
cat /dev/urandom >SCO



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: privilege on usage of cvs import command

[Larry Jones]

Niraj Dave writes:
> 
> Can somebody let me know, how to assign privilege to operate specific
> cvs command by few-previleged users, among many using cvs server.

The only restriction CVS supports directly is for the admin command --
if there's a cvsadmin group on the system, then only members of that
group are allowed to use the admin command.  Some other commands can be
restricted indirectly via the administrative files.  See the manual for
more details.

-Larry Jones

Summer vacation started!  I can't be sick! -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

privilege on usage of cvs import command

[Niraj Dave]

Can somebody let me know, how to assign privilege to operate specific
cvs command by few-previleged users, among many using cvs server.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

cvs import -I ! hangs

[thomas . maciejewski]

I am trying to import a large amount of code from an old project that was
never under source code.

I tried to do a plain import but ALL of the files come back with an I (
Ignored ? )
cd CVS/ProjectA
cvs -m " " -I ! ProjectA ProjectA start

returns:

I ProjectA/foo1.cxx
I ProjectA/foo2.cxx

etc ...

so I read a bit about the ignore list and figured that I dont want to
ignore anything from that distribution so I typed the following line:

cd CVS/ProjectA
cvs -m " " -I ! ProjectA ProjectA start

and it hangs

Any ideas?

Tom





**
The information contained herein is confidential and is intended solely for the 
addresse(s).  It shall not be construed as a recommendation to buy or sell any 
security.  Any unauthorized access, use, reproduction, disclosure or dissemination is 
prohibited.
Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall assume any 
legal liability or responsibility for any incorrect, misleading or altered information 
contained herein.
**



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Files missed during "cvs import"

[Greg A. Woods]

[ On Wednesday, March 5, 2003 at 14:53:50 (-0800), Steve Madsen wrote: ]
> Subject: Files missed during "cvs import"
>
> I have a project that started life as a vendor source snapshot.
> Unfortunately, one directory of files was missed during the initial import
> and later added via "cvs commit".
> 
> Subsequent imports of vendor snapshots are not importing newer versions
> of these files.

Those added files don't have a vendor branch and thus look to "cvs
import" as if they are locally added files (which in fact they are :-).

>  How can I tell CVS to put the latest versions of these files
> on the vendor branch and not treat them as locally modified files?

You should probably re-build that directory by cleaning it out and
starting over.  Save the existing ,v files and use those to re-construct
the local changes (i.e. you will extract and apply the diffs to each
file for each local change re-commit after every iteration, using the
original log message).

> If possible, I would like to do this without re-importing the latest vendor
> snapshot again.

You only have to re-import that one directory, though you should
separately "cvs import" all the vendor releases of that one directory,
interleaving each with any re-commits of the local changes (assuming
there was more than one import done prior to trying to import this
latest vendor release).

You could automate the process with a well planned script, but if there
are only a few local changes to the "missing" files then it's probably a
lot faster and just as reliable to just to it all by hand and be done
with it.

It would be safest to make sure there are no active working directories
anywhere for this module for the duration of this fix-up work.  I.e. get
everyone to commit or store privately any pending changes and to release
all their working directories for this module and especially for the
directory in question.

-- 
Greg A. Woods

+1 416 218-0098;<[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

Files missed during "cvs import"

[Steve Madsen]

I have a project that started life as a vendor source snapshot.
Unfortunately, one directory of files was missed during the initial import
and later added via "cvs commit".
Subsequent imports of vendor snapshots are not importing newer versions
of these files.  How can I tell CVS to put the latest versions of these files
on the vendor branch and not treat them as locally modified files?
If possible, I would like to do this without re-importing the latest vendor
snapshot again.
--
Steve Madsen <[EMAIL PROTECTED]>
Tadpole Computer, Inc.  http://www.tadpole.com


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS import restrict ?

[Ralf S. Engelschall]

On Fri, Feb 07, 2003, R.SANTHANA GOPALAN wrote:

>   Is is possible to restrict the "import" command on the server side ?
> I am using "pserver" authentication model.

AFAIK not with the stock CVS version, but you can apply my CVS patch
set (see http://cvs.openpkg.org/openpkg-src/cvs/cvs.patches.rse) and
use the "importinfo" hook it provides for this. That's what OSSP shiela
(see http://www.ossp.org/pkg/tool/shiela/) successfully uses for access
controlling the "cvs import" operations on the CVS repositories of
OpenSSL, OSSP and OpenPKG.
   Ralf S. Engelschall
   [EMAIL PROTECTED]
   www.engelschall.com



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

CVS import restrict ?

[R.SANTHANA GOPALAN]

Hi,

  Is is possible to restrict the "import" command on the server side ?
I am using "pserver" authentication model.

With regards,
R.SANTHANA GOPALAN.





___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cvs import of (symbolically) linked files

[Kaz Kylheku]

"Jayashree" <[EMAIL PROTECTED]> wrote in message 
news:<[EMAIL PROTECTED]>...
> Hello,
> 
> Can I cvs import symbolically linked directories or linked files in a
> directory?

Again, the answer is Meta-CVS, which handles symbolic links when you
create a project from an existing directory tree, and when you grab
third-party snapshots into an existing project.

Meta-CVS even figures out symbolic links that are renamed, while
following moving targets.

Suppose that your project has this symlink and file, on some branch:

foo -> src/foo.c
src/foo.c

the third party developers give you a snapshot in which src/foo.c is
renamed to sources/bar.c, and the symbolic link is also renamed:

bar -> sources/bar.c
sources/bar.c

Also suppose that the contents of bar.c have changed relative to
foo.c, but not so drastically as to be unrecognizeable.

Meta-CVS's grab command will figure out that sources/bar.c is the same
object as src/foo.c, and that the symbolic link bar is the same object
as the old symbolic link foo, because it chases the same target.

Did I mention that it will record execute permissions as a versioned
property?

http://freshmeat.net/projects/mcvs

> ***
> This message is proprietary to Future Software Limited (FSL) 
> and is intended solely for the use of the individual to whom it
> is addressed.

Namely the entire mailing list and all of Usenet! Right. :)
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cvs import of (symbolically) linked files

[Larry Jones]

Jayashree writes:
> 
> Can I cvs import symbolically linked directories or linked files in a
> directory?

No.  CVS ignores symlinks on import.

-Larry Jones

Hmm... That might not be politic. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cvs import of (symbolically) linked files

[Frederic Brehm]

At 10:32 AM 10/1/2002, Jayashree wrote:
>Can I cvs import symbolically linked directories or linked files in a
>directory?

No. At least it shouldn't. I haven't tried to do that. Maybe you'll get the 
linked file or directory in the repository, but you won't get a link.

CVS does not manage symbolic links. If you really need symbolic links then 
you will have to use your build system to create them.

Fred

___
Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

cvs import of (symbolically) linked files

[Jayashree]

Hello,

Can I cvs import symbolically linked directories or linked files in a
directory?

Regards,
Jayashree

***
This message is proprietary to Future Software Limited (FSL) 
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information 
and should not be circulated or used for any purpose other than for 
what it is intended. 

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. 
FSL accepts no responsibility for loss or damage arising from 
the use of the information transmitted by this email including
damage from virus.
***


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Problem using cvs import with pserver

[Derek Robert Price]

Grace Owen wrote:

>>I am new to CVS and am trying to import a project onto my cvs server
>>using pserver.  I set CVSROOT, and seem to login to the server OK
>>using cvs login.  But when I try to use a cvs import or cvs checkout
>>command nothing happens, it just seems to get stuck until I interrupt
>>it.  i have tried to do the same thing by connecting with ssh, but I
>>get the same problem.
>>
>>Can anyone help?
>>
>>Thanks
>>
>>Grace Owen
>>
>>

http://www.cvshome.org/docs/manual/cvs_21.html#SEC184

Derek

-- 
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at http://ximbiot.com
--
When the only tool you own is a hammer, every problem begins to resemble a
nail.

- Abraham Maslow





___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs