info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

checkout/update bug?


From: Colby Allred
Subject: checkout/update bug?
Date: Wed, 6 Jun 2001 17:00:30 -0700 (PDT)

I've submitted this to bug-cvs, but I thought I'd drop it here as well to
get some comments.  Anyone run into this before?  Anyone able to reproduce
it following my steps below?


Discovered in version 1.10.8
and exibited in 1.11 and 1.11.1p1
using :local: and :ext: access methods
on a RH Linux 6.2 machine.


(Here's the output of cvs version from the 1.11.1p1 binary using :ext:)
~/tmp/test2/cvs_edit_test> cvs version
Client: Concurrent Versions System (CVS) 1.11.1p1 (client/server)
address@hidden's password: 
Server: Concurrent Versions System (CVS) 1.11 (client/server)



Description:  Checkouts/Updates of files that are being 'cvs watch on'ed
and 'cvs edit'ed removes the information about who is editing from the
fileattr file.


Steps to recreate the problem:

SandboxA:
$ echo fileA > fileA
$ echo fileB > fileB
$ cvs add fileA fileB
$ cvs ci -m "adding" fileA fileB
$ cvs watch on fileA fileB
$ rm fileA fileB
$ cvs update fileA fileB

# fileA and fileB are now watched, and read-only

$ cvs edit fileA fileB
$ cvs editors

# reports information like:
fileA   callred Mon Jun  4 21:13:37 2001 GMT    xxx.xxx.aha.com \ 
/nusers/callred/cvs_edit_test
fileB   callred Mon Jun  4 21:13:37 2001 GMT    xxx.xxx.aha.com \ 
/nusers/callred/cvs_edit_test


SandboxB: (i.e. some other directory)
$ cvs co cvs_edit_test 
# (where cvs_edit_test is the module containing fileA and fileB)

cvs checkout: Updating cvs_edit_test
U cvs_edit_test/fileA
U cvs_edit_test/fileB

$ cvs editors

#should return same info as last time, but it returns null.
#running cvs editors in SandboxA also returns nothing, but the files
#in SandboxA still _appear_ as if their being edited.  By _appear_, I
#mean that they still have the write-bit set, there's still copies of
#the files in CVS/Base and entries in CVS/Baserev


Things I've tried:

- as mentioned above, different versions of cvs still exibit same behaviour
- using :ext: access method with CVS_RSH=ssh fails this test
- running an update on locally deleted files from another sandbox fails
the test
- running the update/checkout as another user fails this test

-- 
Colby Allred  address@hidden
Advanced Hardware Architectures
http://www.aha.com/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]