6963: Incoming Changes is not empty even after Update Project

I'm extremely pleased to say that the freezing problem during refreshes of the Changes window is gone! It only took a few minutes to refresh the last 14 days of history too, which is better than it was before. I also like the way the user and date fields have been positioned.

However, I'm still having a problem with the Incoming Changes: Even after using Update Project, I still see lots of entries in the Incoming Changes -- even changes I made that I know for certain are in my working copy. Essentially the Committed and Incoming lists are identical.

I noticed that most of the changes listed are marked as not being on any branch. When I check the Version Control History for some of the files, it definitely highlights the that particular commit as being on a branch. Even weirder, two files from the same commit I made yesterday are showing up as one with branch and one with the correct branch! I checked the files using WinCVS and both have the same branch revision (1.3.2.x) and both have the correct sticky tag for the branch. There were other changelists which had their files split across the ]]> branch and the correct branch.

Files which were added in a branch have a path in the Changed Files which ends in "Attic". Since the Attic is an artifact of the way CVS handles files created on branches, it shouldn't really show up in my view since as far as I'm concerned I did not add the file to a directory called "Attic".

It would be nice to be able to get the Version History for a file in the list of Changed Files. Currently I have to find the file in my project to do that.

It's getting better! :)

0

Any news on this? I'm still seeing the same problem in 7027. My project is checked out on HEAD and up to date, but I see a bunch of changesets from other branches in Incoming Changes, and I get the Outdated warning if I edit a file on HEAD which had a recent commit on some other branch. I'm using CVS, not Subversion, if it makes any difference.

I also agree with Gordon's suggestion above, doing CVS History from the Commited/Incoming windows would be very handy.

0

I'm going to play the broken record here and ask if anything is being done about this? I haven't bothered to install #7041 because it didn't look like it improved anything I was interested in (based on the changelog), so I apologize if improvements have been made in that build.

Since the performance of cvs rlog is abysmal on a repository of some age, I would like to request an option to disable the automatic refreshing of Committed Changes after a CVS Update operation has been performed.

0

Hello Gordon,

I'm going to play the broken record here and ask if anything is being
done about this? I haven't bothered to install #7041 because it didn't
look like it improved anything I was interested in (based on the
changelog), so I apologize if improvements have been made in that
build.


Compared to what? Compared to 6963 - definitely, but there have been no changes
in that area specifically in 7041/7051.

If you still experience problems with the latest EAP, could you please create
a JIRA issue with an attached log file showing the process of pressing Refresh
in Incoming changes?

Since the performance of cvs rlog is abysmal on a repository of some
age, I would like to request an option to disable the automatic
refreshing of Committed Changes after a CVS Update operation has been
performed.


This would effectely disable the feature for displaying the list of update
project results as changelists, because it requires up-to-date Committed
Changes. Is that what you actually need?

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0

Compared to what? Compared to 6963 - definitely, but
there have been no changes
in that area specifically in 7041/7051.


7027 I think was the last one I tried. I'm using 7051 at the moment.

If you still experience problems with the latest EAP,
could you please create
a JIRA issue with an attached log file showing the
process of pressing Refresh
in Incoming changes?


Okay, I'm doing a CVS Update now and I'll refresh the Committed Changes and see how it does.

Since the performance of cvs rlog is abysmal on a

repository of some

age, I would like to request an option to disable

the automatic

refreshing of Committed Changes after a CVS Update

operation has been

performed.


This would effectely disable the feature for
displaying the list of update
project results as changelists, because it requires
up-to-date Committed
Changes. Is that what you actually need?


Couldn't you rather just restrict it to the files which were updated? Just do a CVS rlog on those, and show the commits that were made between the original working copy revision and the newly updated revision.

My problem is that refreshing the committed changes takes a long time. I've never specifically timed it, but it's on the order of 20-30 minutes. While this refresh is going on, all other CVS operations block and cannot be canceled until the refresh is complete.

Admittedly, our repo is old and grungy with defunct branches and binary files that cause cvs rlog take forever. However, there's not a lot I can do about that, and with this situation it makes this feature nearly unusable.

I'll fire JIRA issues for anything that I find in my tests today. I've only been posting messages here because I figured you guys were still working on it and would get annoyed by bug reports for a feature that wasn't complete yet.

0

Hello Gordon,

I'll fire JIRA issues for anything that I find in my tests today. I've
only been posting messages here because I figured you guys were still
working on it and would get annoyed by bug reports for a feature that
wasn't complete yet.


I just fixed a number of issues related to branches and deleted files vs.
CVS incoming changes, so you may be better off waiting for the next EAP. :)

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0

Hello Gordon,

Couldn't you rather just restrict it to the files which were updated? Just do a CVS rlog on those, and show the commits that were made between the original working copy revision and the newly updated revision.

My problem is that refreshing the committed changes takes a long time. I've never specifically timed it, but it's on the order of 20-30 minutes. While this refresh is going on, all other CVS operations block and cannot be canceled until the refresh is complete.

Admittedly, our repo is old and grungy with defunct branches and binary files that cause cvs rlog take forever. However, there's not a lot I can do about that, and with this situation it makes this feature nearly unusable.


Ah, I'm glad I'm not alone: http://www.jetbrains.net/jira/browse/IDEA-13428

The committed/incoming changes feature is great, but the performance of CVS operations suffers a lot
and they need to be more reliable. Especially the yellow editor bar is quite annoying when it tells
you that the file is outdated because of a change you just committed... :/

Sascha

0

Okay, well the refresh didn't take as long as thought, only 10 minutes. Feels like an eternity ;)

Just to verify the behaviour that I'm seeing in the Incoming changes after the refresh so you can tell me if any of it has been fixed and what I should file as issues.

Context: Branch off of HEAD is checked out for 3 separate CVS modules. I just performed a CVS Update for that branch on all 3 directories (CVS Update Project is currently busted and fails immediately due to one of my source directories not being under CVS control -- IDEA-13174). There has been some activity over the last 14 days (the timespan of the refresh) on HEAD for one of the modules and on other branches for all modules.

I'm seeing commits from 2 days ago on another branch of the main CVS module. One of these commits contains one file residing in the Attic (according to the path in the Changed Files list), probably because the file was added on a branch and hasn't been merged to HEAD yet. That seems to be the common feature of all the commits that are showing erroneously -- a file in the Attic.

I'm also seeing commits on HEAD, made by me 2 days ago. Nothing weird about these commits, they're just changes to existing files already on HEAD.

There's one more commit from just a few minutes ago which I think is actually a legitimate incoming change ;) so I've updated it and refreshing the changes. I wish it would update the incoming changes when I use the update files for change list button, without having to refresh the whole commited changes thing.

I'll email you the relevant idea.log section.

Edit: The one commit that I mentioned at the end was a legitimate incoming change. It disappeared from the list after I updated and then refreshed the incoming changes.

0

Hello Gordon,

I'm seeing commits from 2 days ago on another branch of the main CVS
module. One of these commits contains one file residing in the Attic
(according to the path in the Changed Files list), probably because
the file was added on a branch and hasn't been merged to HEAD yet.
That seems to be the common feature of all the commits that are
showing erroneously -- a file in the Attic.


The Attic problem is fixed in next EAP.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0

Yeah, I also filed an issue about this a while back: http://www.jetbrains.net/jira/browse/IDEA-13147.

0

Unfortunately, refreshing Incoming Changes causes an error in IDEA #7065. Filed as http://www.jetbrains.net/jira/browse/IDEA-13710.

0

请先登录再写评论。