"commit->conflict->cancel" causes BIG trouble

( CVSSCC , VS .NET, Latest, WIN 2000/XP, CVS NT 2.0.x )

Type: Public Status:Closed Created: 25 Oct 04 10:00 Updated: 14 Jan 05 01:00

--> Igor Pushkov (admin) at 14 Jan 05 01:00 writes

This is fixed in CVSSCC Proxy NT 2.0 (betta2). We are kindly ask to check
the issue. If it is still exist in new version reopen this ticket.

--> Jan Prochazka (user) at 09 Nov 04 11:00 writes

Thank you for your effort. We are looking forward to CVSSCC version.

--> Igor Pushkov (admin) at 09 Nov 04 11:00 writes

The bug itself casued by incompatibility with 2.0.58 server. However I put
the accepted status to your ticket. Than mean:
a) we will check it when make new release
b) we will add functionality which prevent the problem that I describe. We
will block ability to checkin the files which have conflcits untill you
manyally confirm that you resolve it.

--> Igor Pushkov (admin) at 27 Oct 04 10:00 writes

Ok, I understand... One small question. The client also 2.0.58a, or
you not change anything, and use 2.0.51a shipped with client?

--> Jan Prochazka (user) at 27 Oct 04 10:00 writes

Hello Igor,
I will try to provide you with required information somehow soon. However,
we have hard time now, some our deadliest deadline is approaching in 2
weeks
and all of us are quite (it means 'very') overstretched. So I understand,
you can not do anything if you do not experience the trouble and try to
give
you required info soon.
Just to have complete picture, we use 2.0.58a server. And when we
experience
the trouble CVSSCC message box saying "your sandbox will be no longer in
sync" or "will not longer keep info about your changes" or something like
that, did appear on the screen.
Thanks for your help and sorry for the delay,
Jan

--> Igor Pushkov (admin) at 27 Oct 04 10:00 writes

I checked your issue, and I _not_ have the problems you describe. When I
not reslove conflict, and click "abort checkin" I have all my files as the
was before this. All them are exist in "pending checkins". More other
WinCvs shows the "C" (conflict) state for part of files, and other files it
show as modified. So, behavior is _correct_.

Taking this fact into account, we should find exact resaon of your problem
(if it is really exist, since you wrote them from words of your developer).
To help with this you can:

1. Provide me with screenshot of plug-in options.
2. Provide me with exact sequence of operations.
3. Provide me with snapshot (zip archive) of "bad cvs sandbox" (after
conflict occurs) and "good cvs sandbox".

This will help me to find problem (if it is exist) or point to some
mistakes you can have dealing with this.

--> Igor Pushkov (admin) at 26 Oct 04 10:00 writes

I will check your issue. If it works as you describe this is bug in
our plug-in. The conflict can not be determined on the next
"check-in", but the files should remain "check outed" or "modified".

--> Jan Prochazka (user) at 25 Oct 04 10:00 writes

Our problem is slightly different.
Yes, the scenario is exactly what you described above, but the problem is
that those files looks from cvs point of view as up-to-date unchanged at
the
end. Hence cvs does not know that they need to be checked in (!!!)
If the merging is canceled the best would be to convert sandbox to the
state
where it was before. It would mean that cvsscc would have to create backup
of CVS directories before any "cvs update" is invoked and then explicitly
ask user after he or she close conflict editor, whether the conflict is
resolved and, if it does not, return sandbox to its original state.
I am afraid that i am starting to understand the issue a little bit and
really do not know what to do about that. Probably the best would be to ask
people not to use CVSSCC for committing, but instead use TortoiseCVS:
1) do cvs update
2) resolve any conflicts (canceling is safe in TortoiseCVS)
3) start VS.NET and test the code after conflicts resolved
4) commit the changes (from TortoiseCVS again, just in case to catch any
new
possible conflicts)
But this would degrade a lot reasons why we use cvsscc proxy.

--> Igor Pushkov (admin) at 25 Oct 04 10:00 writes

I will wait for screenshot of plug-in options on the machine where
this happens.
Of course I not 100% sure that all ok in plug-in, but the fact that we
_long_ time did not receive any bugs about conflicts gives me some
trust that all ok.
I know only one problem with postpone conflict resolving (that is
documented) is that CVS show conflict only one time. In other words
follow this scenario:
1. You commit files and got conflict.
2. You press cancel commit, let me resolve conflict.
3. At your working copy _at that_ time will be still _your_ version.
4. You forget to resolve conflicts and commit your files back again.
OPPS, now any conflict found.
The problem caused by the fact, that CVS determined conflict on
update, not the commit. IDE check-in is "csv update" followed by "cvs
commit". You may also know that CVS itself marks conflicted files with
expect that you manually edit file and merge lines between conflict
markers. It will not allow you to commit file until it will see there
conflict markers. This is normal CVS behavior.
However, we found that this is dangerous behavior from IDE point of
view. Conflict markers placed into solution or proj file can make the
unusable. So, before IDE reload file, we remove conflict markers from
file and show conflict editor. Even you not resolve conflict, after
these actions, CVS will think that it is resolved, and not show it for
you again. But files never became broken (will not contain CVS
conflict markers).
The solution is:
a) switch off option "Show conflict editor after update". This way you
will have standard CVS behavior with conflict markers.
b) be more carefully, or better do not use postpone conflict
resolution, and resolve them as soon as they appear (as this is in
SourceSafe).
I think that you may deal with this behavior. But any way I will wait
for developer configuration options.

--> Jan Prochazka (user) at 25 Oct 04 10:00 writes

Hello Igor,
thanks for fast answer.
If it is cvsscc proxy default settings, then yes. No, otherwise; as we do
use "cvs watch on" on the whole repository so the files are checked out as
read only by itself.
yes
Let me ask the developer who experienced the trouble; i'll be back to you
soon
(I personally do not use the proxy for updating, committing and merging so
my setting is irrelevant.)
Best Regards,
Jan

--> Igor Pushkov (admin) at 25 Oct 04 10:00 writes

Few questions:
1. Do you use plug-in with option "Checkout files read-only"?
2. Do you always make checkout (cvs edit) before editing file?
3. Could I see the screenshot of "cvs options" page of plug-in
configuration?

--> Jan Prochazka (user) at 25 Oct 04 10:00 writes

Once somebody tries to commit files that experience CVS conflict, CVSSCC
brings up configured conflict editor. So far so good. But once he or she
wants to postpone merging and hits Cancel, very bad things happen. The
sandbox becomes no longer in sync with the server for all changed files, so
those are not displeyed among "pending checkings". The only workaround what
we found was to check out fresh snadbox somewhere else and do directory
comparison of the original and the new sandbox to find changed files. And
then to copy those changed files from the original sandbox to the new one.
Canceling of merging process e.g in TortoiseCVS does not causes any trouble
and the files can be merged anytime latter.
Do we miss something or does CVSSCC really behaves so bad ? What is
suggested procedure to postpone merging process ?

Rate this ticket:

Not useful at all

Partially useful

Useful

Very useful

Ticket

"commit->conflict->cancel" causes BIG trouble