Community
Participate
Working Groups
I have CVS repository the is working fine with "Change Sets" when I pickup new changes from HEAD. However when I run comparison of the workspace and CVS tag with "Change Sets" it shows lots of "Unassigned Remote Changes". Also when I choose action "Open Change in Compare Editor" for many of those shanges it says that change is new, which is incorrect information.
What CVS server verasion are you using?
I think it is: Concurrent Versions System (CVS) 1.11.5 (client/server) Also here is fragment of the console log with valid requests and responses: Valid-responses ok error M E Checked-in Valid-requests Template Set-sticky Clear-static-directory Module-expansion Set-static-directory Clear-sticky New-entry Merged Removed Updated Remove-entry Update-existing Copy-file Created Notified Mod-time valid-requests Valid-requests Root Valid-responses valid-requests Repository Directory Max-dotdot Static-directory Sticky Checkin-prog Update-prog Entry Kopt Checkin-time Modified Is-modified UseUnchanged Unchanged Notify Questionable Case Argument Argumentx Global_option Gzip-streamwrapper-sendme-rcsOptions Set expand-modules ci co update diff log rlog add remove update-patches gzip-file-contents status rdiff tag rtag import admin export history release watch-on watch-off watch-add watch-remove watchers editors init annotate rannotate noop version ok
This works for me when comaring projects from dev.eclipse.org. Can you try loading the org.eclipse.team.cvs.core project from :pserver:anonymous@dev.eclipse.org:/home/eclipse and comparing it with a previous date to see if it works. If so, that will tell use whether it is a server version issue.
I compared that module to I20050124 tag (first one I picked randomly) and got few files under "Unassigned Remote Changes". All of those files are marked as "+".
I am able to reproduce that. I didn't have any new changes in the comparison I did. The changes in the "Unassigned Remote Changes" bucket are all files that were added since the tag was created. There seems to be a problem getting the comment for these cases. In your previous comment, you said you were getting the + on files that were not new since the tag was created. Is this true (i.e. is there two problems here or just one).
(In reply to comment #5) > I am able to reproduce that. I didn't have any new changes in the comparison I > did. The changes in the "Unassigned Remote Changes" bucket are all files that > were added since the tag was created. There seems to be a problem getting the > comment for these cases. It seems that the same issue exists if file had been removed. Also, if you have uncommitted change on some file it also fail to pull the history on it (they are also appear under unassigned changes). > In your previous comment, you said you were getting the + on files that were > not new since the tag was created. Is this true (i.e. is there two problems > here or just one). Yes. For some changed files under "Unassigned Remote changes" (I have lots of just changed files) if I pick "Open Change in Copare Editor" from popup menu - left panel is empty and label says "File is New".
Would it be possibel for you to provide me with a set of steps to reproduce the "File is new" problem?
(In reply to comment #7) > Would it be possibel for you to provide me with a set of steps to reproduce > the "File is new" problem? Something like this: -- Run comparison to CVS tag. -- Find a changed file (it should not be added or deleted) under "Unassigned Remote Changes" node (double click on this change will show the differnces in editor). -- In popup menu select "Open Change in Comapre Editor" -- Select changed file (in my case it has "+" icon already) and you'll see that left panel is empty and its label says "File is New".
Actually, what I am asking for is an exact set of steps to reproduce. That is, I will need to know the steps (and conditions) that will cause the changed file to appear in the Unassignd" bucket. I know it is sometimes difficult to identify all the factors that are needed to reproduce the problem but without them there is nothing I can do (unless I get lucky and stumble on the same conditions myself).
I'll see if I can find such case in your module.
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.
