This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Assuming you have a large project or slow connection to repository. 1) Checkout same project to different locations. 2) Change some line in one location and commit it. 3) Change the same line in a different way in the second location and save it. 4) In CVS window click Update All and immediately after it Commit All and confirm the commit. Result: As the Update All action has not been completed yet, the Commit All action is queued. BUT even if the update action causes conflict, the commit from the queue still executes and commits the file with conflict! I know, that it is not advisable trying to commit before the update action is completed, but it can happen. And the commit from queue should check, whether the update caused any conflicts. ----- NetBeans IDE Dev (Build 200611290115) 1.5.0_10; Java HotSpot(TM) Client VM 1.5.0_10-b02 Windows XP version 5.1 running on x86 cs_CZ (nb); Cp1250 -----
Hm, nice enhancement. But we should carefully think about it because we do not want to break user workflow. What if the committed file is not touched by the update, etc.
IMHO, this is a defect. Command line also doesn't allow user to commit files in conflicts. This issue doesn't suggest to break user's work flow, but it describes wrong behavior. If there are more actions in a queue and some of them doesn't meet the initial condition (for example: files in conflicts cannot be committed) then all following actions in VCS queue should be canceled and an error dialog should be displayed.
We will NOT commit conflicting files anyway (commit operation will fail). I still do not think this is a defect but will leave it to your judgement.
Actually the commit DOES proceed if it is already in queue. Consider following scenario: There is remotely modified file in the repository, so update could possibly cause conflict. I will modify that file on the same line as was the remote change (so it will definitely cause conflict now) and save it. Now show changes will show locally modified on that file. Still, you have to update before it lets you to commit. BUT if you manage to push Update All and then very fast Commit All and confirm the commit before the update reveals the conflict, the conflicted file WILL be commited! Assuming you have slow connection to the repository, you don't even have to be fast, because it takes a while before the update proceeds and you can put the commit into the queue. THAT is the deffect. It should check whether previous action did cause any conflict before next action from queue is executed.