CVS Import using ANT

2005-01-24 Thread 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


Re: CVS diff and unknown files.

2005-01-24 Thread Sergei Organov
Greg A. Woods [EMAIL PROTECTED] writes:

 [ On , January 21, 2005 at 20:06:37 (+0300), [EMAIL PROTECTED] wrote: ]
  Subject: CVS diff and unknown files.
 
  Is there a way to include contents of unknown files into the 'cvs
  diff' output?
  
  I did try the -N switch but it doesn't seem to do the trick.
 
 You must cvs add the files before they can be seen as new.
 
  I can't 'cvs add' the files as the repository is read-only for me
  (public read-only repository of an open-source project).
 
 Yes, you can, or at least you should be able to.
 
 cvs add does not (and must not :-) contact the server.

Well, it does :( :

$ echo dummy  dummy.txt
$ cvs add -m  dummy.txt
cvs [server aborted]: add requires write access to the repository

-- 
Sergei.



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


Re: CVS Import using ANT

2005-01-24 Thread Gunnar Ahlberg
Hi

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

Example:

  cvs cvsRoot=:pserver:[EMAIL PROTECTED]:/home/cvspublic
   package=ant
   dest=${ws.dir}
  /

/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


Re: CVS diff and unknown files.

2005-01-24 Thread Todd Denniston
Sergei Organov wrote:
 
 Greg A. Woods [EMAIL PROTECTED] writes:
 
  [ On , January 21, 2005 at 20:06:37 (+0300), [EMAIL PROTECTED] wrote: ]
   Subject: CVS diff and unknown files.
  
   Is there a way to include contents of unknown files into the 'cvs
   diff' output?
  
   I did try the -N switch but it doesn't seem to do the trick.
 
  You must cvs add the files before they can be seen as new.
 
   I can't 'cvs add' the files as the repository is read-only for me
   (public read-only repository of an open-source project).
 
  Yes, you can, or at least you should be able to.
 
  cvs add does not (and must not :-) contact the server.
 
 Well, it does :( :
 
 $ echo dummy  dummy.txt
 $ cvs add -m  dummy.txt
 cvs [server aborted]: add requires write access to the repository
Until the Fix that Greg described late last year is put in, you can (I
think) trick cvs at least for files.

***begin cvs_trick_add
#! /bin/bash
echo  /$1/0/dummy timestamp//  CVS/Entries
echo  cvs trick added $1 to the Entries file.
***end cvs_trick_add

cvs_trick_add dummy.txt
-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter


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


Re: CVS diff and unknown files.

2005-01-24 Thread Sergei Organov
Todd Denniston [EMAIL PROTECTED] writes:
[...]
  $ echo dummy  dummy.txt
  $ cvs add -m  dummy.txt
  cvs [server aborted]: add requires write access to the repository

 Until the Fix that Greg described late last year is put in, you can (I
 think) trick cvs at least for files.
 
 ***begin cvs_trick_add
 #! /bin/bash
 echo  /$1/0/dummy timestamp//  CVS/Entries
 echo  cvs trick added $1 to the Entries file.
 ***end cvs_trick_add
 
 cvs_trick_add dummy.txt

Thanks a lot for the trick, Todd! Though I usually try to avoid
temptation to edit CVS/ files manually, it seems that in this case it's
indeed easier than replicating of the whole project into another directory
and using regular 'diff' to compare them.

Glad to hear things are going to be changed in the (hopefully near)
future.

-- 
Sergei.



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


RE: More tag questions

2005-01-24 Thread Christopher.Fouts
Thanks Jim. See embedded responses...

-Original Message-
From: Jim.Hyslop [mailto:[EMAIL PROTECTED] 
Sent: Monday, January 24, 2005 10:20 AM
To: Fouts Christopher (IFNA MP DC); info-cvs@gnu.org
Subject: RE: More tag questions


Christopher Fouts wrote:
 I have a cron job that rtags my integraion branch that
 runs nightly. The cron job does...
   /usr/bin/cvs -d /home/path/cvsroot rtag -r b_proj_dev 
t_br`date 
 +%Y%m%d` proj
 
 It just makes a t_brYYYmmdd tag to the head of my b_proj_dev branch.
 
 I know it works since if I do a...
   cvs history -Ta proj
 
 I get 
   T 2005-01-21 03:00 + user proj [t_br20050120:b_proj_dev]
 
 Now when I do a...
   cvs co -r t_br20050120 proj
 
 I get...
   cvs [checkout aborted]: no such tag t_br20050120
 
 What am I missing?
I can't spot anything obvious. Here are some things you might check:

Does the tag 'b_proj_dev' actually exist in the 'proj' module?

Yes, I use it everyday.


Does a 'cvs stat -v' or a 'cvs rlog' on one of the files in 
the project show the tag, or something similar?


Yes, just did it, and the t_brmmdd tag shows on a couple of
files I tried.

Can you capture the stdout and stderr output of the cron job, 
and examine it for any clues?

I'll do this later.


Does the command work properly if you type it in interactively?

Yes. I did this manually for testing before I even ran the cron job.


-- 
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
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs


RE: More tag questions

2005-01-24 Thread Jim.Hyslop
Christopher Fouts wrote:
 I have a cron job that rtags my integraion branch that
 runs nightly. The cron job does...
/usr/bin/cvs -d /home/path/cvsroot rtag -r b_proj_dev
 t_br`date +%Y%m%d` proj
 
 It just makes a t_brYYYmmdd tag to the head of my b_proj_dev branch.
 
 I know it works since if I do a...
cvs history -Ta proj
 
 I get 
T 2005-01-21 03:00 + user proj
 [t_br20050120:b_proj_dev]
 
 Now when I do a...
cvs co -r t_br20050120 proj
 
 I get...
cvs [checkout aborted]: no such tag t_br20050120
 
 What am I missing?
I can't spot anything obvious. Here are some things you might check:

Does the tag 'b_proj_dev' actually exist in the 'proj' module?

Does a 'cvs stat -v' or a 'cvs rlog' on one of the files in the project show
the tag, or something similar?

Can you capture the stdout and stderr output of the cron job, and examine it
for any clues?

Does the command work properly if you type it in interactively?

-- 
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
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs


Re: recursive checkout in existing directory

2005-01-24 Thread Larry Jones
Steve Sapovits writes:
 
 -  If I import a new directory, all the way down recursively,
 ignoring what I need, then if I checkout that new directory
 in the existing tree, it replaces the old directory with only
 the files I imported.

No.  CVS *never* removes a file that it doesn't own.  What should happen
in that case is that CVS should checkout the files into the existing
directory tree, complaining about any existing file with the same name
as one it is trying to checkout (and skipping the checkout for that
file).  In reality, CVS doesn't work very well in this case (and exactly
what it does is almost certainly different depending on whether you're
using client/server mode or not).  It has a tendency to refuse to
recurse into existing subdirectories at all, and you may get additional
errors.  But it will never remove or replace an existing directory or
file.

 -  If I import a subdirectory first, then check that out, a CVS
 directory is created at the top, thereby preventing me from
 recursively checking out anything new after import.  For example,
 if I import foo/a/b, then check it out, then import the rest
 of foo/a, which includes subdirectories foo/a/c, foo/a/d, etc.,
 then the previous checkout of foo/a/b has created a CVS presence
 that stops any of the subdirectories from being checked out
 recursively.

No, you can still checkout additional subdirectories.  You can even
checkout completely unrelated subdirectories from a completely different
repository, if you want!  The only thing you can't do is have files from
different repository directories in the same working directory.  That
said, the right thing to do in this particular case is to use update
-d in the top-level working directory to update it with the new
subdirectories.

-Larry Jones

Well of course the zipper's going to get stuck if everyone
stands around WATCHING me! -- Calvin


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


Re: Help, can't use the %-5d option in CVS diff command.

2005-01-24 Thread Larry Jones
vse fischer writes:

 MIME-Version: 1.0
 Content-Type: multipart/alternative; boundary=0-1709973163-1106312379=:50386

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

 I want to use the line/group format specifier to generate a difference
 report with a user specified output format, but the %-5d format
 specifier doesn't work.

Doesn't work is a bit nebulous.  Can you give a complete example
showing the command you used, the result you got, and an explanation of
how that differs from what you expected?

-Larry Jones

I'm writing you a message in code.  How do you spell nincompoop? -- Calvin


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


Re: 2GB limitation: out of memory problem.

2005-01-24 Thread Larry Jones
Paul writes:
 
 During a CVS commit I got the following error message: 
 cvs [server aborted]: out of memory; can not allocate x bytes

You need to increase the amount of (virtual) memory available to the CVS
server.  Exactly how to do that is highly system dependent.

-Larry Jones

I don't need to do a better job.  I need better P.R. on the job I DO.
-- Calvin


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


Re: recursive checkout in existing directory

2005-01-24 Thread Steve Sapovits
Larry Jones wrote:
No.  CVS *never* removes a file that it doesn't own.  What should happen
in that case is that CVS should checkout the files into the existing
directory tree, complaining about any existing file with the same name
as one it is trying to checkout (and skipping the checkout for that
file).  In reality, CVS doesn't work very well in this case (and exactly
what it does is almost certainly different depending on whether you're
using client/server mode or not).  It has a tendency to refuse to
recurse into existing subdirectories at all, and you may get additional
errors.  But it will never remove or replace an existing directory or
file.
I thought that should be the case, as I have used CVS in the past.
But we've seen this a few times now.  Maybe it's a bug of some
sort?  We're running 1.11 on a Solaris platform.  I'll see if I
can reproduce it.
We admittedly have a poor set-up here I'm trying to work around
without disrupting things.
Thanks for the feedback.
--
Steve Sapovits[EMAIL PROTECTED]
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs


Re: CVS diff and unknown files.

2005-01-24 Thread Paul Sander
On Jan 24, 2005, at 6:20 AM, [EMAIL PROTECTED] wrote:
Todd Denniston [EMAIL PROTECTED] writes:
[...]
$ echo dummy  dummy.txt
$ cvs add -m  dummy.txt
cvs [server aborted]: add requires write access to the repository
Until the Fix that Greg described late last year is put in, you can (I
think) trick cvs at least for files.
***begin cvs_trick_add
#! /bin/bash
echo  /$1/0/dummy timestamp//  CVS/Entries
echo  cvs trick added $1 to the Entries file.
***end cvs_trick_add
cvs_trick_add dummy.txt
Thanks a lot for the trick, Todd! Though I usually try to avoid
temptation to edit CVS/ files manually, it seems that in this case it's
indeed easier than replicating of the whole project into another 
directory
and using regular 'diff' to compare them.

Glad to hear things are going to be changed in the (hopefully near)
future.
It's unclear if that particular change will be made, or if made whether 
or not it will stay.  The requirement to supply add-time triggers has 
been identified (by a number of users), which requires a contact with 
the server.  This has undergone some heated debate.

--
Paul Sander   | Lets stick to the new mistakes and get rid of the 
old
[EMAIL PROTECTED] | ones -- William Brown


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


Re: CVS diff and unknown files.

2005-01-24 Thread Sergei Organov
Paul Sander [EMAIL PROTECTED] writes:
 On Jan 24, 2005, at 6:20 AM, [EMAIL PROTECTED] wrote:
 
  Todd Denniston [EMAIL PROTECTED] writes:
  [...]
  $ echo dummy  dummy.txt
  $ cvs add -m  dummy.txt
  cvs [server aborted]: add requires write access to the repository
 
  Until the Fix that Greg described late last year is put in, you can (I
  think) trick cvs at least for files.
 
  ***begin cvs_trick_add
  #! /bin/bash
  echo  /$1/0/dummy timestamp//  CVS/Entries
  echo  cvs trick added $1 to the Entries file.
  ***end cvs_trick_add
 
  cvs_trick_add dummy.txt
 
  Thanks a lot for the trick, Todd! Though I usually try to avoid
  temptation to edit CVS/ files manually, it seems that in this case it's
  indeed easier than replicating of the whole project into another directory
 
  and using regular 'diff' to compare them.
 
  Glad to hear things are going to be changed in the (hopefully near)
  future.
 
 It's unclear if that particular change will be made, or if made
 whether or not it will stay. The requirement to supply add-time
 triggers has been identified (by a number of users), which requires a
 contact with the server. This has undergone some heated debate.

Well, the problem described is in fact not in contacting with server,
but in requiring write access to the repository.

Is there any sound reason why 'cvs add' and 'cvs remove' commands
require *write* access to the repo?

-- 
Sergei.



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


PAM Authentication?

2005-01-24 Thread Jeff Smith
I am trying to bring cvs into my company.  I am
working with one of our Solaris admins on getting the
product installed and configured. 

We have run into a problem with getting the PAM
authentication working.  

I really don't know anything about PAM, my admin
probably does, but we have followed the instructions.

We compiled it with PAM enabled.  He modified the
pam.conf file and added these lines:

cvsauth required   pam_unix.so.1
cvsaccount requiredpam_unix.so.1
cvssession requiredpam_unix.so.1

When I do the command:

cvs -d :pserver:[EMAIL PROTECTED]:/cvs login
it does prompt for a password, and I put in the right
one.

But I get:
cvs login: authorization failed: server cvsdev
rejected access to /cvs for user y24jds

In the /var/adm/messages, I see the output:


cvs[26366]: [ID 926525 daemon.notice] login failure
(for /cvs)

I looked and found where pam_unix.so.1 was located and
put that in the LD_LIBRARY_PATH variable in the
.profile for the cvs userid.  I don't know if that
was necessary, but I tried it.

We also might have another complication entering in. 
Our Unix servers run a very intrusive security program
called E-Trust.  It is so powerful that it can even
limit what root can do.  We have a data security team
that administers it, but trobuleshooting with them can
be difficult sometimes and I'm not really sure it is a
factor yet.

Where do I start trying to troubleshoot this? 

Thanks!

Jeff


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


Re: CVS diff and unknown files.

2005-01-24 Thread Larry Jones
Sergei Organov writes:
 
 Is there any sound reason why 'cvs add' and 'cvs remove' commands
 require *write* access to the repo?

CVS add of a directory modifies the repository, but I suspect the actual
motivation was the principle that you should tell someone that they're
not allowed to do what they're trying to do as soon as possible rather
than as late as possible.

-Larry Jones

Philistines. -- Calvin


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


Re: CVS diff and unknown files.

2005-01-24 Thread Todd Denniston
Sergei Organov wrote:
 
 Paul Sander [EMAIL PROTECTED] writes:
  On Jan 24, 2005, at 6:20 AM, [EMAIL PROTECTED] wrote:
SNIP
  It's unclear if that particular change will be made, or if made
  whether or not it will stay. The requirement to supply add-time
  triggers has been identified (by a number of users), which requires a
  contact with the server. This has undergone some heated debate.
 
 Well, the problem described is in fact not in contacting with server,
 but in requiring write access to the repository.
 
 Is there any sound reason why 'cvs add' and 'cvs remove' commands
 require *write* access to the repo?
 
I believe what Paul means, is that no one has yet owned up to writing or
submitted the patches to implement the changes.

Please see the linked thread to answer your question.
Greg  I believe there is no need in the normal case for add to contact the
repo, especially to write, unfortunately it is currently implemented to
connect.
Paul had a case for desiring in certain cases to contact the server on add.
Both cases _are valid_, my desire would be for add to contact the server
only when an extra flag is passed.
http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=add+hook+question+%28wassubmit=Search%21idxname=info-cvsmax=20result=normalsort=date%3Aearly

http://lists.gnu.org/archive/html/info-cvs/2004-11/msg00150.html
http://lists.gnu.org/archive/html/info-cvs/2004-11/msg00188.html

the trick I showed you is the fake I was speaking of in:
http://lists.gnu.org/archive/html/info-cvs/2004-11/msg00191.html

Please understand the linked thread before posting much on this, as the heat
got kind of high the last time we discussed it.

-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter


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


Re: PAM Authentication?

2005-01-24 Thread Todd Denniston
Jeff Smith wrote:
 
 I am trying to bring cvs into my company.  I am
 working with one of our Solaris admins on getting the
 product installed and configured.
 
 We have run into a problem with getting the PAM
 authentication working.
 
 I really don't know anything about PAM, my admin
 probably does, but we have followed the instructions.
 

Which instructions?
I see no PAM here
https://www.cvshome.org/docs/manual/cvs-1.11.18/cvs_26.html#INDEX1_6
Or here
https://www.cvshome.org/docs/manual/cvs-1.12.11/cvs_27.html#INDEX2_2


Is y24jds a username at the OS level, i.e., not just for CVS?
if it is then pserver should just use the system's login, or something close
to it, which would automatically use PAM.

SNIP
 When I do the command:
 
 cvs -d :pserver:[EMAIL PROTECTED]:/cvs login
 it does prompt for a password, and I put in the right
 one.
 
 But I get:
 cvs login: authorization failed: server cvsdev
 rejected access to /cvs for user y24jds
 
 In the /var/adm/messages, I see the output:
 
 cvs[26366]: [ID 926525 daemon.notice] login failure
 (for /cvs)
SNIP
 We also might have another complication entering in.
 Our Unix servers run a very intrusive security program
 called E-Trust.  It is so powerful that it can even
 limit what root can do.  We have a data security team
 that administers it, but trobuleshooting with them can
 be difficult sometimes and I'm not really sure it is a
 factor yet.

Is there a reason why you have chosen pserver as your connection method?
From the sound of it, your group would be a bit more on the paranoid side
and would expect after reading a bit on pserver security
https://www.cvshome.org/docs/manual/cvs-1.12.11/cvs_2.html#SEC33
http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=pserver+securitysubmit=Search%21idxname=info-cvsmax=20result=normalsort=date%3Alate
that pserver would be disallowed.

I would have more expected you to use :ext: with CVS_RSH=rsh or CVS_RSH=ssh
https://www.cvshome.org/docs/manual/cvs-1.12.11/cvs_2.html#SEC29

 
 Where do I start trying to troubleshoot this?
https://www.cvshome.org/docs/manual/cvs-1.12.11/cvs_21.html#SEC210
 
 Thanks!
 
 Jeff

-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter


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


Security Breach Alert - CVS Home File Download Area Compromised

2005-01-24 Thread Conrad T. Pino
 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello All,

It's been brought to my attention the *.sig files in the Max OS X
can't be downloaded as they appear to have zero file size.  I have
confirmed this report and have confirmed the issue in the Solaris
i386 area as well.

On further investigation of a limited sample set, every file I have
sampled now downloads with a substantially larger size than the size
on the download page and larger than the size of the reference copy I
maintain.

Although my sample size is quite small the error rate is 100% which
I believe is sufficient cause to raise an alarm.

Until such time as the state of www.cvshome.org can be determined, I
recommend the CVS community refrain from downloading files or do so
with extreme caution.

I would appreciate all binary maintainers please sample their uploads
and report deviations to Brian Noble of Collab Net who is copied in
this message.

I would appreciate someone stepping forward to assume responsibility
for coordinating an investigation into this issue.

Best regards,

Conrad T. Pino
(510) 848-3929

-BEGIN PGP SIGNATURE-
Version: PGP 7.0.4

iQA/AwUBQfVsYrNM28ubzTo9EQLDaACdF+j1YPDchv5Lz4iDI9yptoQq11kAn3C0
+oEtYdKUiPrwpZFqGWc74kaH
=MUnr
-END PGP SIGNATURE-



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


RE: Security Breach Alert - CVS Home File Download Area Compromised

2005-01-24 Thread Conrad T. Pino
 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Here are the MD5 hashes for the reference copies I
maintain of files I've uploaded to www.cvshome.org:
=
MD5 (cvs-1-11-14.zip) = 35ec8ff6b00a752c5183ab3748f9dae5
MD5 (cvs-1-11-15.zip) = cf35a5ed948182e4c41d874473dc9212
MD5 (cvs-1-11-16.zip) = 5d8a154b23da7e46ced62712b93d6939
MD5 (cvs-1-11-17.zip) = dbaf26eb74d5d4fa5201bb82f0d858ac

MD5 (cvs-1-12-6.zip) = 13e28e80eced3d6fb0edaac10e55875e
MD5 (cvs-1-12-7.zip) = 1bf8609af647f42e40d42b10404c54a9
MD5 (cvs-1-12-8.zip) = 2e4496adb2cde63daf71fcf63ddf3b54
MD5 (cvs-1-12-9.zip) = 41e9a3e53b97eff53381a5d49eec27e3
MD5 (cvs-1-12-10.zip) = 61c390e8ac223a82f5f2bc172c7f5142
MD5 (cvs-1-12-11.zip) = a1f664fc365be3784dc28aad90ddde4a

MD5 (cvs-1.11.11-SunOS-5.8-i386.gz) = 35608cc22fa1cae86f43cb9336a5e12e
MD5 (cvs-1.11.12-SunOS-5.8-i386.gz) = 12d35bc5e9cbda9db9e70ed6c6431f36
MD5 (cvs-1.11.13-SunOS-5.8-i386.gz) = bc42352adffee96ba78a1b36780b7216
MD5 (cvs-1.11.14-SunOS-5.8-i386.gz) = 8288ec02c88747d515195901c599fad3
MD5 (cvs-1.11.15-SunOS-5.8-i386.gz) = 7b61d3fe7e3fbb05f85cf7552c06e9db
MD5 (cvs-1.11.16-SunOS-5.8-i386.gz) = 3fadf697fbcc56bfa6e0452c65cb5717
MD5 (cvs-1.11.17-SunOS-5.8-i386.gz) = 3bf31f8acf91fdd984a3e97dd73120d0
MD5 (cvs-1.11.18-SunOS-5.8-i386.gz) = 5d88c104ef5b35b2996a44fa34a39170

MD5 (cvs-1.12.5-SunOS-5.8-i386.gz) = 26c1c727812a8634ffa14febf40568ce
MD5 (cvs-1.12.6-SunOS-5.8-i386.gz) = 5291e60c22ec558d8c573dd06010f0d2
MD5 (cvs-1.12.7-SunOS-5.8-i386.gz) = d7f067cde9673405d182077c465fde5a
MD5 (cvs-1.12.8-SunOS-5.8-i386.gz) = 03f644f0a970583802254eae09c31961
MD5 (cvs-1.12.9-SunOS-5.8-i386.gz) = ded0d1b33ca596c38978d53a14ba9e2a
MD5 (cvs-1.12.10-SunOS-5.8-i386.gz) = ef8f5c19753152eed8c479705b322261
MD5 (cvs-1.12.11-SunOS-5.8-i386.gz) = 956f5d64382cc21e73dc40cc65211a71

MD5 (cvs-1.11.17-Darwin-7.7.0-powerpc.gz) = 204fa37dbdba47eb770eabe358c753be
MD5 (cvs-1.11.18-Darwin-7.7.0-powerpc.gz) = 4f8d5bb4a3bb187a464dba0e0648e7b7

MD5 (cvs-1.12.10-Darwin-7.7.0-powerpc.gz) = ac58da09fd04f2c35cec9e8df684c630
MD5 (cvs-1.12.11-Darwin-7.7.0-powerpc.gz) = 48b4cb61d7bbc500d74dc8ef735f4961
=
MD5 (cvs-1-11-14.zip.sig) = 0199d794783f9bc49ec4220cf74dc380
MD5 (cvs-1-11-15.zip.sig) = f0b275251088b6faf015fa9b61c806ed
MD5 (cvs-1-11-16.zip.sig) = 9daa5245d9a78ccb3e6643ce3af2f929
MD5 (cvs-1-11-17.zip.sig) = cc6934206b9261b9801d1ca6678fbc4d

MD5 (cvs-1-12-6.zip.sig) = 7b8741389ded01b8191437638df41e6f
MD5 (cvs-1-12-7.zip.sig) = ebe515b81f37531c962facb6e480229b
MD5 (cvs-1-12-8.zip.sig) = 2c7ce9b5441c40689efa1ed20c948f78
MD5 (cvs-1-12-9.zip.sig) = aba74b2a61686513656e53e45e097e5a
MD5 (cvs-1-12-10.zip.sig) = f1f2fd0c64d9b277a2feed0b6b1d24de
MD5 (cvs-1-12-11.zip.sig) = 5e2938ea5bd5ce4a6dfd1a6f4d254f69

MD5 (cvs-1.11.11-SunOS-5.8-i386.gz.sig) = f0fb1f8d6623f9119865bced0c6df409
MD5 (cvs-1.11.12-SunOS-5.8-i386.gz.sig) = 00ee94d3378110f518752dcec39abd6e
MD5 (cvs-1.11.13-SunOS-5.8-i386.gz.sig) = 9a753846b34af475cf2703eeba36e17f
MD5 (cvs-1.11.14-SunOS-5.8-i386.gz.sig) = 14147a4cb0aa9178dbccb03ec37a1cf2
MD5 (cvs-1.11.15-SunOS-5.8-i386.gz.sig) = bbef9969131b652a37ab107a2c3bdfb4
MD5 (cvs-1.11.16-SunOS-5.8-i386.gz.sig) = 617e5bef8761778d7702a0c80319a0e3
MD5 (cvs-1.11.17-SunOS-5.8-i386.gz.sig) = 987cf6680826954c46de88fdd85d4d1a
MD5 (cvs-1.11.18-SunOS-5.8-i386.gz.sig) = fa2f3d6bcb621baf4b3265385c6632a7

MD5 (cvs-1.12.5-SunOS-5.8-i386.gz.sig) = aaba7be9e311020b5033470123612db6
MD5 (cvs-1.12.6-SunOS-5.8-i386.gz.sig) = 54b4e7be7ddc33c1c96e0aea66e27b29
MD5 (cvs-1.12.7-SunOS-5.8-i386.gz.sig) = faaf04278db6feb4e0a4f766516d2f3d
MD5 (cvs-1.12.8-SunOS-5.8-i386.gz.sig) = c6079c8940b9e55fbb54875c89780b8e
MD5 (cvs-1.12.9-SunOS-5.8-i386.gz.sig) = 11b2addd5df92c6bbdfbb33615058878
MD5 (cvs-1.12.10-SunOS-5.8-i386.gz.sig) = f2677b8eab23c1416efd627b5f0417b0
MD5 (cvs-1.12.11-SunOS-5.8-i386.gz.sig) = 1ca8b559f37e2cd68744ea751b75c519

MD5 (cvs-1.11.17-Darwin-7.7.0-powerpc.gz.sig) = a9d92e1b34e04cf8a41ab4cc2cd03afa
MD5 (cvs-1.11.18-Darwin-7.7.0-powerpc.gz.sig) = 9d51550960acca14ec206712f03d1177

MD5 (cvs-1.12.10-Darwin-7.7.0-powerpc.gz.sig) = fadbd96885e71755370529e362a3f17a
MD5 (cvs-1.12.11-Darwin-7.7.0-powerpc.gz.sig) = 9fac303d55d7185addbbf54866460df3
=

-BEGIN PGP SIGNATURE-
Version: PGP 7.0.4

iQA/AwUBQfV2K7NM28ubzTo9EQJX5QCgrolL/4o9QgBMHe/uMXIouSzeyywAnjxl
TS+MzNZRXACbRzouxBSNA1ZE
=ZqzM
-END PGP SIGNATURE-



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


Re: recursive checkout in existing directory

2005-01-24 Thread Steve Sapovits
I wrote:
I thought that should be the case, as I have used CVS in the past.
But we've seen this a few times now.  Maybe it's a bug of some
sort?  We're running 1.11 on a Solaris platform.  I'll see if I
can reproduce it.
I must have been on drugs here.  I do not see this behavior
at all, no matter how I test.  In addition, at least one of
the other cases of CVS removing existing files has been
identified as a side effect of a bad manual copy someone did.
I adopted the model of having our wrapper script checkout into
a clean directory then do a controlled copy over the existing
files (with checks, etc.).  That eliminates any issues and is
working fine.
Thanks for the help.
--
Steve Sapovits[EMAIL PROTECTED]
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs


RE: Security Breach Alert - CVS Home File Download Area Compromised

2005-01-24 Thread Conrad T. Pino
 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello All,

I've done a preliminary systematic check and here's
what I know so far:

1. The issue may be client platform specific.

2. Not all download areas are affected but I still
recommend considering the entire system suspect
until a complete determination is made.

Supporting specific details follow:
===
I'm seeing an issue using Windows 2000 SP4 + Updates
and Internet Explorer 6.0.2800.1106 and the symptoms
are as follows:

A. All sampled *.gz.sig will not download.

B. All sampled *.gz files start downloading with
the expected file size but the download reaches the
expected file size and then continues to a file size
much larger than expected.

The Mac OS X user who brought the issue to light has
different symptoms:

a. The sampled *.gz.sig will not download.

b. The sampled *.gz files download with correct size
and the MD5 hashes agree with my reference copy.

The Mac OS X sample size is likely just a single file.
===
The Windows file download area appears unaffected so
far but I have NOT compared ALL files as yet.

I. All sampled (4) *.zip.sig files download and
compare to my reference copies correctly.

II. All sampled (4) *.zip files download and
compare to my reference copies correctly.

Although the Windows download area appears unaffected
so far I still recommend caution.
===
The Solaris i386 and Mac OS X binary are affected as
follows:

i. The 8 sampled files *.gz.sig will not download.

ii. The 8 sampled files *.gz files start downloading
with the expected file size but the download reaches
the expected file size and then continues to a file
size much larger than expected.
===
The AIX, HP, SIG and Solaris SPARC download areas are
similar to Solaris i386 and Mac OS X areas as follows:

There are no *.gz.sig files to verify.

The 4 sampled files *.gz files start downloading with
the expected file size but the download reaches the
expected file size and then continues to a file size
much larger than expected.
===
Best regards,

Conrad T. Pino

-BEGIN PGP SIGNATURE-
Version: PGP 7.0.4

iQA/AwUBQfWGwbNM28ubzTo9EQJQ5gCaA+ks6TmSQhf76Eqgu78R/ivtIb8AoKya
ftj4EdHElKntr7urLQZuMUsK
=1mJh
-END PGP SIGNATURE-



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


RE: Security Breach Alert - CVS Home File Download Area Compromised

2005-01-24 Thread Conrad T. Pino
 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi All,

 From: Conrad T. Pino
  
 ===
 The Solaris i386 and Mac OS X binary are affected as
 follows:
 
 i. The 8 sampled files *.gz.sig will not download.
 
 ii. The 8 sampled files *.gz files start downloading
 with the expected file size but the download reaches
 the expected file size and then continues to a file
 size much larger than expected.

A preliminary check of downloaded content indicates the
download content may be a code payload:

An hexadecimal dump utility of reference (I:) and the download (U:) copy:

dump i:cvs-1.12.11-Darwin-7.7.0-powerpc.gz  dumpi.txt
dump u:cvs-1.12.11-Darwin-7.7.0-powerpc.gz  dumpu.txt

reveals dumpi.txt to be:

00:  1F 8B 08 08 FA 88 E9 41 - 00 03 63 76 73 2D 31 2E  z.iA..cvs-1.
10:  31 32 2E 31 31 2D 44 61 - 72 77 69 6E 2D 37 2E 37  12.11-Darwin-7.7
20:  2E 30 2D 70 6F 77 65 72 - 70 63 00 EC FD 7D 7C 54  .0-powerpc.l}}|T
30:  D5 F1 00 8C 9F BB BB D9 - 4D 30 B4 8B 2E 35 40 A2  Uq...;;YM04..5@
40:  89 04 1B 24 40 A8 D0 DE - B0 09 EC 86 50 2F 06 DA  ...$@(P^0.l.P/.Z
50:  A0 A1 80 82 26 24 28 60 - 68 83 84 B2 D1 4D F6 2E   !..$(`h..2QMv.
60:  59 DA 44 C1 06 02 35 48 - 92 26 40 14 2A 50 50 68  YZDA..5H.@.*PPh
70:  41 08 06 79 F9 82 42 0B - 0A 15 2A 20 51 A8 41 A1  A..yy.B...* Q(A!

80:  C5 0A 2D 54 70 9F 99 39 - E7 EE BD BB 09 B4 FD FD  E.-Tp..9gn=;.4}}
90:  9E 3F 1F 3E 9F 25 F7 E5 - DC F3 32 67 CE 9C 99 39  .?..%we\s2gN..9
A0:  F3 F2 CD A5 7F FF 91 31 - 76 27 E3 FF 4C F0 BB 83  srM%...1v'c.Lp;.
B0:  31 6B 31 FC 5D 08 3F 09 - 7E F2 93 4F E6 BA 1F 1A  1k1|].?.~r.Of:..
C0:  FD D8 E8 47 7E CC 0C FF - EC EC 16 FF 2C FC 3B 93  }XhG~L..ll..,|;.
D0:  E3 C9 27 F3 46 4F CA 8B - F8 26 66 13 BF E4 7F 6D  cI'sFOJ.xf.?d.m
E0:  F0 8B 12 7F D9 93 4F 96 - 4E F7 94 EA A5 3B 7F DF  p...Y.O.Nw.j%;._
F0:  2B 83 D9 3E F0 C0 C7 19 - A2 AF F4 4F A5 26 B5 6F  +.Y[EMAIL 
PROTECTED]/tO%5o

and dumpu.txt to be:

00:  FE ED FA CE 00 00 00 12 - 00 00 00 00 00 00 00 02  ~mzN
10:  00 00 00 0B 00 00 06 6C - 00 00 00 85 00 00 00 01  ...l
20:  00 00 00 38 5F 5F 50 41 - 47 45 5A 45 52 4F 00 00  ...8__PAGEZERO..
30:  00 00 00 00 00 00 00 00 - 00 00 10 00 00 00 00 00  
40:  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00  
50:  00 00 00 04 00 00 00 01 - 00 00 02 14 5F 5F 54 45  __TE
60:  58 54 00 00 00 00 00 00 - 00 00 00 00 00 00 10 00  XT..
70:  00 09 B0 00 00 00 00 00 - 00 09 B0 00 00 00 00 07  ..0...0.

80:  00 00 00 05 00 00 00 07 - 00 00 00 00 5F 5F 74 65  __te
90:  78 74 00 00 00 00 00 00 - 00 00 00 00 5F 5F 54 45  xt..__TE
A0:  58 54 00 00 00 00 00 00 - 00 00 00 00 00 00 19 3C  XT.
B0:  00 07 D3 78 00 00 09 3C - 00 00 00 02 00 00 00 00  ..Sx...
C0:  00 00 00 00 80 00 04 00 - 00 00 00 00 00 00 00 00  
D0:  5F 5F 70 69 63 73 79 6D - 62 6F 6C 5F 73 74 75 62  __picsymbol_stub
E0:  5F 5F 54 45 58 54 00 00 - 00 00 00 00 00 00 00 00  __TEXT..
F0:  00 07 EC B4 00 00 00 00 - 00 07 DC B4 00 00 00 02  ..l4..\4

An hexadecimal dump utility of reference (I:) and the download (U:) copy:

dump i:cvs-1.12.11-SunOS-5.8-i386.gz  dumpi.txt
dump u:cvs-1.12.11-SunOS-5.8-i386.gz  dumpu.txt

reveals dumpi.txt to be:

00:  1F 8B 08 08 F4 4F BF 41 - 00 03 63 76 73 2D 31 2E  tO?A..cvs-1.
10:  31 32 2E 31 31 2D 53 75 - 6E 4F 53 2D 35 2E 38 2D  12.11-SunOS-5.8-
20:  69 33 38 36 00 8C 9B 07 - 78 54 45 F7 C6 17 48 76  i386xTEwF.Hv
30:  CF DD 0D 29 10 8A 48 09 - 3D F4 00 01 03 84 1E 20  O].)..H.=t. 
40:  52 03 44 6A 54 84 A8 34 - 11 21 08 2A 4A C0 20 48  R.DjT.(4.!.*J@ H
50:  47 69 2A 6A 84 48 13 A5 - 88 02 0A 0A 02 4A 37 20  Gi*j.H.%.J7 
60:  22 28 22 25 F8 21 20 04 - 0C 4D 50 BF 77 92 77 77  (%x! ..MP?w.ww
70:  CF FF 7E 8B CF 7F 9F E7 - E5 9C DF 39 33 73 E7 CE  O.~.O..ge._93sgN

80:  CE 9D 3B F7 6E 98 D0 AE - 73 FB 42 85 0A 39 BC 9F  N.;wn.P.s{B..9.
90:  C2 8E 22 0E 43 F3 A6 07 - 4B 2C EC 86 85 CD F2 E3  B..Cs.K,l..Mrc
A0:  B1 8E 28 47 B0 23 DA 51 - CE 51 C6 E1 CC 67 A3 60  1.(G0#ZQNQFaLg#`
B0:  31 B9 4C 2A 98 6D 14 81 - 8E 38 FC 9F 08 DA 20 5A  19L*.m...8|..Z Z
C0:  FF D1 0A EA F7 DB 6B E5 - 2B 98 59 93 4F 01 A7 EC  .Q.jw[ke+.Y.O.'l
D0:  0D CB CF 9F 0F 71 38 CE - 55 72 38 5C CC 17 36 6D  .KO..q8NUr8\L.6m
E0:  1D B0 A0 82 FC 31 B6 E6 - A2 AD 37 66 F4 A8 7A C3  .0 .|16f-7ft(zC
F0:  87 0C AC 37 3C B5 EE E8 - A7 EB D6 37 B1 BE E8 54  ..,75nh'kV71hT

and dumpu.txt to be:

00:  7F 45 4C 46 01 01 01 00 - 00 00 00 00 00 00 00 00  .ELF
10:  02 00 03 00 01 00 00 00 - 94 8B 05 08 34 00 00 00  

RE: Security Breach Alert - CVS Home File Download Area Compromised

2005-01-24 Thread Conrad T. Pino
 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi All,

I have contacted the www.cvshome.org hosting provider
(Collab Net) by phone and learned that Brian Noble is
away from the office this week.

Brian's supervisor, Philippe Turpault provided this
information and now has copies of my prior messages
on this issue.

Best regards,

Conrad T. Pino

-BEGIN PGP SIGNATURE-
Version: PGP 7.0.4

iQA/AwUBQfWffLNM28ubzTo9EQIF0ACgyikh9fzUnFbPNs4aSbM86unQ3SkAnR80
gBhzB+cdL8W7F+1S28juITb7
=8z4Q
-END PGP SIGNATURE-



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


Re: CVS on OS X, Tortoise client on PC

2005-01-24 Thread mattmattmatt
Tom,

Thanks for responding.  I went with CVSNT because TortoiseCVS is built
on it as well (feature comparison breakdown here:
http://www.cvsnt.com/cvspro/compare.htm).

I actually found that it was not my CVS installation on X, but rather
some sort of issue with the Tortoise client (which I had originally
tried with the standard CVS that is so common and could not get to work
either).  I have now found success with *both* the eclipse CVS tool as
well as a Java frontend called SmartCVS, which I like a lot
(http://www.smartcvs.com)

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