[ https://jira.jboss.org/browse/JBIDE-7732?page=com.atlassian.jira.plugin.s... ] Brian Fitzpatrick updated JBIDE-7732: ------------------------------------- Fix Version/s: 3.2.0.CR1 Koen, can you look into this again? -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBIDE-7732?page=com.atlassian.jira.plugin.s... ] Koen Aers updated JBIDE-7732: ----------------------------- Fix Version/s: LATER (was: 3.2.0.CR1) Priority: Minor (was: Critical) Joe, this seems not really a critical issue anymore. Is there any way you can provide a patch or at least a detailed description of the editor hooks that you talk about? -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBIDE-7732?page=com.atlassian.jira.plugin.s... ] joe freeman updated JBIDE-7732: ------------------------------- Summary: fixe for JBIDE-3915 breaks version control for SCM that require checkout for writable files (was: fixe for JBIDE-1029 breaks version control for SCM that require checkout for writable files) Description: JBIDE-3915 tried to fix the issue where the JBPM xml editor fails when editing non-writable files. The fix (015307?) in the URL below offers the user the opportunity to change the attributes from r/o to r/w bypassing the SCM hooks. So for an SCM like Perforce where all files are locked until checkout, the user will have changed the R/W bits without notifying the SCM so they can save their changes but they never get committed back to the repository. Users can lose changes without knowing it. If you answer NO to the panel offered by JBIDE-1029 then the editor will still let you edit and when you save it will check out the processdefinition.xml in the SCM file like it used to and will fail on the gpd and jpg files (like it used to). The fix should have used the same Eclipse hooks used by the editor so that all 3 files end up checked out. Changing the access bits directly seems like a bad idea http://lists.jboss.org/pipermail/jbosstools-commits/2009-September/015307... https://jira.jboss.org/browse/JBIDE-3915 was: JBIDE-1029 tried to fix the issue where the JBPM xml editor fails when editing non-writable files. The fix (015307?) in the URL below offers the user the opportunity to change the attributes from r/o to r/w bypassing the SCM hooks. So for an SCM like Perforce where all files are locked until checkout, the user will have changed the R/W bits without notifying the SCM so they can save their changes but they never get committed back to the repository. Users can lose changes without knowing it. If you answer NO to the panel offered by JBIDE-1029 then the editor will still let you edit and when you save it will check out the processdefinition.xml in the SCM file like it used to and will fail on the gpd and jpg files (like it used to). The fix should have used the same Eclipse hooks used by the editor so that all 3 files end up checked out. Changing the access bits directly seems like a bad idea http://lists.jboss.org/pipermail/jbosstools-commits/2009-September/015307... https://jira.jboss.org/browse/JBIDE-1029 -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBIDE-7732?page=com.atlassian.jira.plugin.s... ] joe freeman commented on JBIDE-7732: ------------------------------------ I fixed the related-to jira. I'm not sure how I ended up with the other issue number. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBIDE-7732?page=com.atlassian.jira.plugin.s... ] joe freeman commented on JBIDE-7732: ------------------------------------ I'm claiming that the fix made in 2009 was probably "incorrect" behavior with respect to SCM systems that require checkout to make files writable. If I edit a Java file in eclipse while using Perforce as my SCM, the editor somehow checks out the file. The SCM plugin is somehow invoked to check out the file which makes it writable and adds the label decoration to the file. When I do the same thing in JBPM editor (post 3.1.0 M3) the editor offers to make the files writable. If it does that the files can be edited but the label decoration don't show up in the outline views and the SCM client doesn't see that the files have been made writable. If, on the other hand, you say no to the "do you want me to make these 3 writable", then the editor will still (incorrectly) let you edit the file and then it attempts to save the file. That save operation triggers the SCM hooks for the processdefinition.xml only. That file gets saved, the label decorations added and the file is added to the SCM (Perforce in this case) change list. The other two files fail to save for some reason. I'm guessing their save path is different because they are saved out side of some editor framework. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira