View Issue Details

IDProjectCategoryView StatusLast Update
0000779JEDI VCSServerpublic2009-12-06 01:47
ReporterUSchusterAssigned ToUSchuster 
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version 
Target VersionFixed in VersionREL_2.4.4.815 
Summary0000779: a revision can checked in more than one time
DescriptionA least CHECKIN_MODULE allows to check in a revision more than one time. When two ore more people check in a revision nearly at the same time the newest revision will contain the files twice(or more).
Additional InformationThis happend today. I made a small fix on a module, but didn't checked it out. I opened the check in dialog and entered the checkin comment and hit the "Check In" button.
After that I opened the module history and saw the files twice in the latest revision. In that time I entered the check in comment one of my colleagues checked out and checked in the same file.
My "revision" had an other RevisionID but the same revision. All the files get the RevisionID from the first revision which was checked in.
CHECKIN_MODULE doesn't check if the revision still exists and guess that SELECT delivers the RevisionID which was generated in the INSERT statement before.

CHECKIN_MODULE should check if the revision still exists.
Thats also somethings which we should keep in mind with connection of a multithreaded server.
TagsNo tags attached.
Fix in JVCS version
Releasedocumentationhistory

Relationships

child of 0002361 closedTHuber JEDI VCS Releaseinfo: 2.40 server issues 
child of 0004500 closedTHuber JVCS Server applications Releaseinfo: 2.44 server issues 

Activities

MGosselink

2003-04-14 03:49

developer   ~0001927

Extra check added in "CHECKIN_MODULE". If the module is ready to be checked in, the (new) revision will be checked if it already exists. If so an error message appears.

USchuster

2009-06-15 00:15

manager   ~0015671

The issue is only fixed for the case when the module is not checked out. If a module is checked out then the check isn't performed.

Issue History

Date Modified Username Field Change
2005-01-15 05:46 THuber Relationship added child of 0002361
2005-06-13 16:43 THuber Status resolved => closed
2005-06-13 16:43 THuber Fixed in Version => 2.40 Stable (Server)
2009-06-15 00:13 USchuster Assigned To MGosselink => USchuster
2009-06-15 00:13 USchuster Status closed => feedback
2009-06-15 00:13 USchuster Resolution fixed => reopened
2009-06-15 00:15 USchuster Note Added: 0015671
2009-06-15 00:15 USchuster Status feedback => confirmed
2009-06-15 00:17 USchuster Relationship added child of 0004500
2009-08-31 23:50 USchuster Releasedocumentation => history
2009-08-31 23:50 USchuster Status confirmed => resolved
2009-08-31 23:50 USchuster Fixed in Version 2.40 Stable (Server) => REL_2.4.4
2009-08-31 23:50 USchuster Resolution reopened => fixed
2009-12-06 01:47 THuber Status resolved => closed