CVS diff showing wrong data as the repository version

Anyone seen a problem where CVS differences (either the left gutter marks or the diff shown in the commit window) are being taken agains the wrong version?

I have a file with only one remote version (1.1). I did lots of changes to this file, and now it's finally time to commit. While I'm looking at the CVS commit window, I request the file diff, as I usually do -- and noticed that the version show in the "Repository version" pane is NOT the repository version, but some intermediate version showing some of the changes made after the last repository version.

Now, while this bug isn't really destructive (I'm not losing the CVS history or anything like that), it's VERY misleading; I always request diffs before commit to make sure I'm not doing any inadvertent changes, and showing the wrong version in the diff panel can lead to disastrous conclusions.

Am I alone in this? Also, how could I gather enough data to help JetBrains isolate this bug? What should I send to you, guys? I'll hold on commiting this file for as long as I can.

11 comments
Comment actions Permalink

To make sure this isn't lost in the forums:

http://www.jetbrains.net/jira/browse/IDEA-2574

0
Comment actions Permalink

Yes, I've seen this before. It appears that the CVS Commit Project
dialog uses Local History to show the diffs, instead of the actual diff
from the repository. I've seen this problem occur with the editor gutter
change markers as well.

I think there's a backlog issue for this, from a Tracker item I posted a
long time ago.

--
Gordon Tyler (Software Developer)
Quest Software <http://www.quest.com/>
260 King Street East, Toronto, Ontario M5A 4L5, Canada
Voice: (416) 933-5046 | Fax: (416) 933-5001

0
Comment actions Permalink

I can't believe that the project diff works like that. I had endless problems with SourceSafe in my last job - because the plugin didn't work that well, I had to use the client a lot, and local history became totally broken and unuseable. If I ask for a project diff, that's what I want to see.

0
Comment actions Permalink

There's nothing wrong with using the local history for showing diffs in the commit window, given that the remote revision probably has a correspondent revision in the local history. Problem is, IDEA needs to get this right ;)

Anyways, I attached a lot of (hopefully) relevant data to the above cited jira issue. Let's cross our fingers and hope Jetbrains can use this to find and fix the bug.

0
Comment actions Permalink

Marcus Brito wrote:

There's nothing wrong with using the local history for showing diffs in the commit window, given that the remote revision probably has a correspondent revision in the local history. Problem is, IDEA needs to get this right ;)


Wouldn't that only be true if you were the only one who was modifying the file? Shouldn't
IDEA consider the possibility of concurrent modifications so that the local history is no
longer representative of what is in the repository?

0
Comment actions Permalink

Wouldn't that only be true if you were the only one
who was modifying the file? Shouldn't
IDEA consider the possibility of concurrent
modifications so that the local history is no
longer representative of what is in the repository?


Actually, no. When you request a diff in the commit window, you're checking the differences between the version you checked out (not necessarily the latest in the repository) and the current (edited) version.

0
Comment actions Permalink

Actually, yes. If i'm going to check something in, I need to see what it's going to get get merged into, not just my changes against a possibly out of date target.

0
Comment actions Permalink

But that's a different issue; there should be a separate action for this.

N.

Glenn McGregor wrote:

Actually, yes. If i'm going to check something in, I need to see what it's going to get get merged into, not just my changes against a possibly out of date target.

0
Comment actions Permalink

But that's a different issue; there should be a
separate action for this.


That already exists: "Compare with latest repository version" , and thankfully works correctly.

I understand your motivation to get a diff against the latest version before checking in, but that's not the usual CVS workflow; to start with, CVS won't let you commit if the latest version on the server is not the version you checked out. If that happens, you will have to update, resolve conflicts, and then commit.

0
Comment actions Permalink

The last time I tried 'compare with latest repository version' I got a comparison with HEAD, not the branch I had checked out. Not what I find useful.

0
Comment actions Permalink

Eh, you're right... this bug has been around for quite some time. I guess I'm a happy CVS user, very rarely delving into non-HEAD branches.

0

Please sign in to leave a comment.