It's all about the answers!

Ask a question

File permissions in SCM


Jeff Care (1.0k3833) | asked Jan 04 '11, 4:37 p.m.
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?

Comments
Jeff Care commented Jan 05 '11, 4:58 p.m. | edited Aug 28 '13, 11:20 a.m.
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?



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.

9 answers



permanent link
Geoffrey Clemm (30.1k33035) | 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
system allows this.

What about restoring those permissions during the file extract for a
build?

Comments
Jeff Care commented Jan 06 '11, 2:25 p.m. | edited Aug 28 '13, 11:22 a.m.

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.


permanent link
Geoffrey Clemm (30.1k33035) | 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:
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
system allows this.

What about restoring those permissions during the file extract for
a
build?


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.

permanent link
Tim Feeney (30745745) | answered Feb 28 '12, 5:23 p.m.
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
system allows this.

What about restoring those permissions during the file extract for a
build?


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.

permanent link
David Lafreniere (4.8k7) | answered Feb 29 '12, 12:20 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
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.

permanent link
Tim Feeney (30745745) | answered Mar 01 '12, 1:07 p.m.
JAZZ DEVELOPER
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?

permanent link
David Lafreniere (4.8k7) | answered Mar 01 '12, 2:09 p.m.
FORUM MODERATOR / JAZZ DEVELOPER


Hmm that's strange, not that I know of. I just tried and for me it's a drop down allowing me to either select "true" or "false". What version of RTC are you trying? (In the meantime I'll try to find when that functionality was added).

permanent link
Tim Feeney (30745745) | answered Mar 01 '12, 2:19 p.m.
JAZZ DEVELOPER


Hmm that's strange, not that I know of. I just tried and for me it's a drop down allowing me to either select "true" or "false". What version of RTC are you trying? (In the meantime I'll try to find when that functionality was added).


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.

permanent link
David Lafreniere (4.8k7) | answered Mar 01 '12, 5:28 p.m.
FORUM MODERATOR / JAZZ DEVELOPER
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.

permanent link
Tim Feeney (30745745) | answered Mar 01 '12, 5:32 p.m.
JAZZ DEVELOPER
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


Register or to post 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.