Bug 205784

Comment 1 Jakub Jurkiewicz 2007-11-15 11:16:51 EST

Created attachment 82974 [details]
Patch

While working on this patch I observed a strange situation: [after trying to change ASCII/Binary properties of a file in] the method CVSLightweightDecorator#extractFileProperties(IFile resource, CVSDecoration cvsDecoration) the information in [code]fileInfo.keywordMode[/code] and [code]option[/code] was different and I guess that this was the reason why the decorator was changed when it shouldn't be. This was because while performing the changing of the ASCII/Binary properties of a file some information was changed at the beginning, but it was not reversed when the operation failed. My idea for resolving this is to keep the necessary information before running the changing command and revert it when the command fails.
Any comments are welcomed.

Comment 2 Tomasz Zarna 2007-11-20 07:23:02 EST

Your guess is right: "fileInfo.keywordMode" is based on CVS Entry file on the workspace side while "option" is based on the file content[1]. So, when you change a keyword for a text file to binary the options will probably differ.

Your second assumption is also correct, but let me shed more light on what is happening there: after "admin" command for the file is executed we are using AdminKSubstListener[2] to capture lines of text that are sent back to us as a response to the command[3]. The answer we get in this particular situation looks like this:

cvs admin -kb "<workspace path to the file>"
    RCS file: <rcs path to the file>,v
    cvs server: admin -k no longer affects future checkins.  Use update -k / commit -f instead.
    done
ok (took 6:55.860)

The problem is that we interpret the lines separately, so the AdminKSubstListener first updates the local ResourceSyncInfo (as a response for line starting with "RCS file:...") but then the next line says that there has been an error. We do handle the error but the local ResourceSyncInfo is not reversed.

Anyway, your patch is fine but I think it would be worthwhile to understand how the AdminKSubstListener works and maybe fix the issue at that level.

[1] See KSubstOption#fromFile(IFile)
[2] org.eclipse.team.internal.ccvs.core.client.listeners.AdminKSubstListener
[3] See org.eclipse.team.internal.ccvs.core.client.Request#executeRequest

Comment 3 Jakub Jurkiewicz 2007-11-22 05:21:50 EST

Thanks Tomasz for putting some light on it. 
I will try to look closer and see what can be done.

Comment 4 Eclipse Webmaster 2019-09-06 16:19:04 EDT

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.

Comment 5 Eclipse Genie 2021-11-14 08:48:08 EST

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.