Read Only Share

[edonaldson]

Forgive me if I missed this in the documentation, but I couldn't find anything really fit what I need to accomplish.

Scenario:
We have a template website that we build all of our other sites from. This template is the latest and greatest set of code for our sites.
When we build a new customer website, we currently branch the template folder into a new folder. For instance, if we have two new clients, we will branch template to client1 and client2.

client1 decides they want to change the home page. no problem. We edit the file, and commit the changes. Since it's branched, it only affects this client.
Client2 decides they want to do the same. Same as above.

Now we find a bug in the template that we need to correct. So, we change the template folder file.
Of course, now we need to propogate that change to the rest of the clients, so they don't run into the same bug. However, since we branched, then we need to Merge Branch with each of the clients. Not a big deal when there are two clients, but in really, there are hundreds of clients.

So, we thought about sharing. Sharing would take care of the bug fixes very easily. And client modified files could be branched before they are edited, allowing the best of both worlds. However, it's this second condition that causes some concern. With a team of developers, it becomes cumbersome for developers to have to check each client file they need to edit to ensure that it has been branched already. Otherwise, because the file is shared, they will affect the websites of all other clients. That would be...bad.

So, I was hoping that there was some sort of "readonly" share. The template would "share" it's folders to client sites, but those files cannot be edited on the client sites without first being branched. Even some sort of indicator saying the client file is a "share" would be helpful (but still dangerous), or a warning saying the client file is still a share copy.

Is this making any sense? Am I missing something obvious?

Thanks.

[avonwyss]

You can pin a share to a specific version, which in fact makes it read-only and the version will not change when doing a get latest of that share unless you change the pin. I guess this may help you.

Note: I'm not a Sourcegear staff

[edonaldson]

But I don't want the client sites to be pinned to a specific version of the template. I want them to always use the most current version (i.e. the share), but not be able to edit those shared files (i.e. readonly) unless they are branched first.

[avonwyss]

Well, you do see the file as shared in the Windows GUI client. I'm not sure what happens if you use folder permissions to try to achieve what you want, it may work...

[lbauer]

There's no built-in way to do this in Vault. Any permission set on the shared folder is the same for the share link. If you change permission on one, it automatically changed on the other.

One possibility would be for clients to have read-only access to the folder for the template. They could diff this folder with their website folder. If there are changes, they could do a Get of files that had been modified, checkout their website folder, then replace/add files from the updated template folder.

If this might be an option, I can provide more detail.

[edonaldson]

I think I have found a problem:

I have a repository that uses folder permissions

$/solution3/a has R access for user1, and RCA for user2
$/solution3/b has RCA access for user1 and RCA for user2

$/solution3/a/file1, file2 are "shared" to $/solution3/b. This could not be done by user1, I assume because they only have R access to /a. So, they were shared using user2.

user1 cannot checkout $/solution3/a/file1. They don't have permissions. Good.
However, user1 CAN checkout $/solution3/b/file1, make changes to it, and the changes get SHARED back to /a/file1. That seems...very very bad.

The idea of a limited set of users being able to edit the /a/ folder but a larger set being able to edit the /b/ folder seems broken.

[avonwyss]

Actually, the behavior you're describing is better than what I expected. In fact, I believe that this is the ideal behavior.

[edonaldson]

I'm not sure how this could be an "ideal" solution. You have a set of files that you want to share between multiple projects, but you don't want the files to be changed by any random vault user that may affect all other projects. More specifically, you don't want a developer to inadvertently change a file that is shared among many projects, because, at least in Visual Studio, there is no indication that the file you are editing is shared or "local". It can just be changed, and then all the rest of the projects are likewise changed, even though that is not the intended result.

In essence, in the current system, there is no way to "lockdown" a set of pages so that they can only be edited by a certain group of users, and still allow them to be shared to other projects.

[avonwyss]

You can pin them and I think you can lock the share itself down using folder permissions (have you tried this?), so there are some options from my point of view.

Also, I think that the current behavior is ideal because it does exactly what it is told to do: stuff underneath folder a cannot be changed by user 1, stuff underneath folder b can - even if these are in fact (by use of the share) the same files.

You have to be aware that a share does not have the notion of a "master", all shares of one file or folder are equal. Shares are basically just several entries for the same files or folders, you do not have one file and some additional links to it. You can, for instance, simulate a file or folder move by sharing them to the new location and deleting the old share.

Therefore, I'd suggest that you make sure that file1 (in your sample) is in its own folder, and that this folder denies write access for user1 underneath folder b. This may do what you are trying to achieve.

[lbauer]

Let us know if avonwyss' suggestions help.

[edonaldson]

It helps, in that it provided clarity on the difference between a share and a "master" relationship. We were thinking of the master relationship, and that's not what a share is.

But "pinning" also doesn't accomplish what we need. Doesn't that "pin" the resulting file/folder to a specific version of the original? We want it to be "pinned" to the latest version, until we need to branch a copy to make changes.

Correct?

[avonwyss]

Doesn't that "pin" the resulting file/folder to a specific version of the original? We want it to be "pinned" to the latest version, until we need to branch a copy to make changes.

A non-pinned file is always on the latest version (when Get Latest is performed). So just using the folder permissions on the shares may be the solution for your needs?