Community
Participate
Working Groups
I20050209 - I had jdt-core version v_535, in source - wanted to make a selective update to HEAD contents of jdt-core -> compare with...>branch or version -> select head - in the synchronize view, I chose to show commit sets (as I wanted only updates of a single commit set) expected: the displayed commit sets would be the ones of the HEAD commits (showing what had changed from v_535 to HEAD) actual: the commit sets were based on the revisions i had in my workspace
The problem is that the rlog command is not fetching all the relevant revisions in this case. We will need to special case this and try to come up with a set of rlog parameters that give the desired result. The workaround is to load HEAD and comare against the Tag. That results in the proper change sets.
I can't confirm comment 1. I had HEAD in my workspace and compared againt an older tag. All change sets were labelled with the commit comment of the old revision, and added files were in a change set labelled "Unassigned Remote Changes". I would expect to see the commit comment of the newest revision in both cases.
No time to address this in 3.1
This is still a pain. It also makes the preview page of the releng tool's Release command completely unusable when change sets are enabled, because all shown comments are from the second-to-last commit.
I believe that the Platform/UI co-op has been adding improvements to the release wizard to get the correct comments. Hopefully it will be available soon but it has been delayed a bit due to the fact that the CVS protocol just isn;t geared to give this information.
This let me panic today when doing the build input for 3.2.2: I got a full list of changes and started to investigate why. This is a major bug which should either be fixed by showing the correct change sets or by disabling the change set mode in those situations where we cannot compute the correct info.
In order to prevent pain: as a simple fix couldn't you simply disable the change set feature in these situations?
We will consider only providing Change Sets for Synchronizations and remove them for Compares.
Created attachment 75545 [details] Initial patch This patch solves the problem for the case were you compare against a version tag. It works by making the assumption that the first fetched revision is not a change and can be ignored. Although this may be the correct assumption, I am going to investigate adding a more definitive test but that requires including the tags in the fetch of the log info. Also, I will need to add the logic for comparing against a data and for comparing against HEAD or a branch.
Michael, any progress here? Do you want to hand it over to us? I can give it a try, but won't make during 3.4. So, 3.5 seems to be closer to reality.
I am not looking into this anymore. Feel free to take it over.
Pawel is on it, however it looks like 3.5.1.
Since the Compare between branches is just a two way compare I don't get how Change Sets concept fits there. I mean I can see the point of grouping changes but can't see how we could use CVS commit comments for that. All we should do when the command is invoked is compare two states, the local state with the state on a given branch. I think what we're missing here is a "Synchronize with Another Branch or Version..." command. This would give the point in the repository tree to act as a base for the comparison (the last common revision for two branches). Lack of the command makes people use "Compare With > Another Branch or Version..." to do the job it's not designed to do. Using "Synchronize with Another Branch or Version..." we could use commit comments to show what changes were made on a branch we're synchronizing to as incoming. The changes made in the branch we're in should be labelled with appropriate commit comments to and marked as outgoing. And the local changes should be unassigned and outgoing to. However, as I discussed the problem with Szymon and Tomasz, there are some still some unknowns regarding how "Synchronize with Another Branch or Version..." should operate. Consider the case in which a file was modified on both branches plus we made some changes to it locally. Which commit set should it belong to? To summarize, I'd drop the Change Sets from Compare With. I mean not the concept, just automatically constructing them from commit comments. Then I'd consider adding "Synchronize with Another Branch or Version...".
Regarding the recent comments and feedback from Dani I'm removing the target milestone. We'll set more realistic one when we have feedback from anyone interested in fixing this. I'll add it to our list of issues being considered for 3.6 (http://wiki.eclipse.org/Workspace3.6)
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
