[Top][All Lists]

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

Bug: remote repository zombies

From: Artur Klauser
Subject: Bug: remote repository zombies
Date: Wed, 20 Nov 2002 20:57:06 +0100 (CET)

I think this is a bug - unless somebody convinces me that its a feature.

Bug Summary:
CVS (trunk) leaves file in the Attic, while its UNdead - its a zombie!

 - Repository module "foo" with one file "bar". Just a trunk, no branches.
 - The repository is remote, not on the local file system. I use 
   CVS_RSH=ssh to access the remote repository. I have also verified that
   the same problem exists with rsh. Did not try pserver.
 - There are 4 users, John, Paul, Mary, and Jane. 3 of them have an
   up-to-date working copy, the 4th one does not have a checkout yet.

 * commands to do this:
     setenv CVSROOT cvsserver.mydomain.com:/cvsroot
     mkdir foo
     cd foo
     echo "This is bar" > bar
     cvs import -m init foo init INIT
     cd ..
     cvs co -d foo-john foo
     cvs co -d foo-paul foo
     cvs co -d foo-mary foo

The Problem:
 - John and Paul are happily developing. John is removing file bar and
   commits this change. Paul in the meantime is changing his file bar, 
   later  does an update (to get John's changes) and then does a commit.
 - The problem is that Paul's update goes through and leaves his local
   file bar in 'Locally Modified' status, rather than failing with 
   'Unresolved Conflict'.

 * commands to do this:
     cd foo-john
     cvs rm -f bar
     cvs com -m "John: preparing for zombie" bar
     cd ../foo-paul
     perl -pi -e "s/bar/a zombie/;" bar
     # (1) bar is in status "Needs Merge" - already a bad sign (see later)
     cvs upd bar
     # (2) Here is the ERROR! cvs says ...
     #   Merging differences between and 1.2 into bar
     #   bar already contains the differences between and 1.2
     # ... and leaves bar in status "Locally Modified"
     cvs com -m "Paul: creating the zombie" bar
     # now we have the zombie: bar is in the Attic, but alive!

 - The behavior now is as follows:
   - If Mary does an update to her already existing copy, she sees Paul's 
     change and the status of her file bar is "Up-to-date".
   - If Jane now checks out a new copy of this directory, she sees John's
     view (ie. the deleted file) and thus does not get a copy of the file.
     The repository state is incoherent - two different users have to
     different views of how the up-to-date files look like!

 * commands to do this:
     cd ../foo-mary/
     cvs upd bar
     # bar gets updated with Paul's change (Paul's view)
     # no CVS update ever removes Mary's file bar
     cd ..
     cvs co -d foo-jane foo
     # directory foo is empty (John's view)
The Correct Behavior:
 - When you repeat the same steps as above on a local repository, at stage 
   (1) the cvs status of file bar will be in status 'Unresolved Conflict' 
   instead of 'Needs Merge', and the cvs update will fail with the message
     cvs update: conflict: bar is modified but no longer in the repository
   which I would consider the right behavior. Paul has to (a) either delete 
   his copy of bar throwing away the changes that he did after John has 
   committed the delete of bar, or resurrect bar before being able to check 
   in changes to it.

 * commands to do this:
     setenv CVSROOT $HOME/mycvsroot
     cvs init
     # then the same sequence of steps as above until you hit comment (2)
     # where cvs on the local repository behaves correctly


reply via email to

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