[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!
Setup:
- 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 1.1.1.1 and 1.2 into bar
# bar already contains the differences between 1.1.1.1 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
-r2r-
- Bug: remote repository zombies,
Artur Klauser <=