File permissions in SCM
Is there a way to store file permissions in SCM? Our current SCM system allows this.
What about restoring those permissions during the file extract for a build? |
9 answers
Geoffrey Clemm (30.1k●3●30●35)
| answered Jan 05 '11, 11:38 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
No, RTC does not store/restore file permissions, except for the
"execute" bit (which only applies to Unix systems, since Windows using the extension of the file to determine executability, not an execute bit). One of the challenges with storing/restoring file permissions in a cross-platform system like RTC is that different file systems have very different file permission models (e.g. Windows and Unix). Cheers, Geoff On 1/4/2011 4:38 PM, carej wrote: Is there a way to store file permissions in SCM? Our current SCM Comments Are there plans in place to provide this feature? Is there a feature request that I can subscribe to and add our requirements? The lack of this functionality is a major step backwards for us. |
|
Geoffrey Clemm (30.1k●3●30●35)
| answered Jan 07 '11, 12:23 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
There is a work item 118445 for per-file read-access control.
If you would like to see more than that, you'd want to create a separate work item. Make sure you indicate how you would want the cross-platform problem mentioned below solved. Cheers, Geoff On 1/6/2011 2:38 PM, carej wrote: gmclemmwrote: Are there plans in place to provide this feature? Is there a feature request that I can subscribe to and add our requirements? The lack of this functionality is a major step backwards for us. |
No, RTC does not store/restore file permissions, except for the Is there a way to store file permissions in SCM? Our current SCM So if the file was first versioned with the execute bit not set, how do you later set it in a way that the versioned copy can be updated in the repository? I have a situation where files were delivered while the execute was not set. Now when they are loaded, developers need to go about and manually change he execute bit. We want to update the files in RTC so that subsequent loads have the bit set. This is on a SUSE Linux system. |
So if the file was first versioned with the execute bit not set, how do you later set it in a way that the versioned copy can be updated in the repository? If the files are loaded into the Eclipse client, from the Package Explorer you can right-click on the resource --> Properties --> Jazz Source Control. This page will let you modify properties for that resource such as the executable flag, MIME type and lime delimiter. Making changes to these will result in a local change, allowing you to then create a change set and deliver those changes to the rest of the team. |
So if the file was first versioned with the execute bit not set, how do you later set it in a way that the versioned copy can be updated in the repository? If the files are loaded into the Eclipse client, from the Package Explorer you can right-click on the resource --> Properties --> Jazz Source Control. This page will let you modify properties for that resource such as the executable flag, MIME type and lime delimiter. Making changes to these will result in a local change, allowing you to then create a change set and deliver those changes to the rest of the team. That's where I looked first but it is not editable. I have tried it against several different files. I can edit MIME type and line delimiter but the Executable property is display only. Does this require a certain role/permission? |
|
|
I am on the GA version of 3.0.1. I have tried this both on a SUSE Linux system against our development project and my Win 7 laptop running the MTM sample. It looks like this is the work item which touched this feature recently: "181772: Executable file property doesn't work as expected" (https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/181772) and looks like the fix will only be available in RTC 4.0. However the description does say "chmod +x on a file within unix workspace and a subsequent check in will store the execute bit in Jazz Source Control" so hopefully that will work. |
I am on the GA version of 3.0.1. I have tried this both on a SUSE Linux system against our development project and my Win 7 laptop running the MTM sample. It looks like this is the work item which touched this feature recently: "181772: Executable file property doesn't work as expected" (https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/181772) and looks like the fix will only be available in RTC 4.0. However the description does say "chmod +x on a file within unix workspace and a subsequent check in will store the execute bit in Jazz Source Control" so hopefully that will work. Thanks David. I am pretty sure we've tried that but I will have them try again. |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
Just to clarify, this question is not about access control within RTC itself, but about the actual permissions on the files once they have been "loaded" (either in a sandbox or for a build) as in, "I want file XYZ to have permission 755 on disk".
Without this capability our build logic will be doing lots of chmod'ing.