bug-cvs
[Top][All Lists]
Advanced

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

Conflict-related code deletion


From: Chris Horn
Subject: Conflict-related code deletion
Date: Wed, 20 Nov 2002 20:00:03 -0500

Greetings; our team has discovered a rather unpleasant CVS behavior.

On the Debian Linux server:
$ cvs -v
Concurrent Versions System (CVS) 1.11.1p1 (client/server)

On the Win2k workstations:
WinCVS 1.3.8.1 Beta 8(Build 1)


This behavior occurs only rarely, and results in the loss of one person's edits. Below are the specific steps to reproduce the problem. Chris and Tom are two not-so-fictional CVS users.

1. Chris and Tom have revision 1.11 of file.txt
2. Chris edits line 5 of file.txt and commits it to the server
3. The server revision is now 1.12
4. Tom edits line 5 of file.txt and tries to commit to the server
5. Tom receives an up-to-date check failed error (as he should)
6. Tom updates file.txt and conflict text is filled in around line 5
7. Tom opens file.txt and resolves the conflict
8. Chris changes line 5 of file.txt again, and commits it to the server
9. The server revision is now 1.13
10. Tom tries to commit his conflict resolution (from step 7)
11. Tom receives an up-to-date check failed error
12. Tom updates his file, and loses his edit to line 5.
13. Tom and Chris now have revision 1.13

The bug is that Tom's changes to line five have been lost. CVS has failed in that it has not notified him that there was *another* conflict. We have not checked to see whether Tom's other edits to file.txt would have also been stripped.

Things untested:

1. If Tom modified line 7, would his changes be dropped as they were on line 5?
2. If Tom modified line 4 and Chris modified line 4 during his creation of 1.13, would Tom's edits be dropped as they were on line 5?

Please cc: chorn@rand.org as I am not on the bug-cvs mailing list.

Thank you.
chris horn.

-----
chorn@rand.org
703.413.1100 x5100





reply via email to

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