Preventing users from checking-out files in a specific branch

[jimbo1999]

Hello,

 

We're currently evaluation Plastic with a view to moving away from our ancient simple VCS system (which only allows one repository with exclusive checkout per file - unusable now we have a team of 10). As some of the developers have been using this system for decades I want to minimise the change to the basic VCS functionality while making the usefulness of things like merging available, but while preventing accidental misuse of the system.

 

I've set up a single repository with a "Release" root branch, then created a child branch called "SystemTest". Basically developers will create a branch for each task they are doing then merge these branches into the SystemTest to pass to our testing team. When we want to release we'll merge from SystemTest into the Release branch and stamp it with a version.

 

What I'm trying to do is prevent developers checking any files out of the Release or SystemTest branches, but allow them to create their own child branches which they have full access to and can merge back into SystemTest when they're finished. I've turned on "Update and Checkin operations set files as read-only" which means that an explicit check-out is required for each file, but can't see an option to prevent check-out in the permissions list for a branch (or anywhere else for that matter). So as it stands a developer can check out the file from the SystemTest branch, modify it but then will only realise they're on the wrong branch when they come to check in, which is something that I suspect would happen a lot. Does such a permission exist? It seems to be referred to in the 3.0.1 manual (permission "co") but I can't see it in the client GUI I'm using (5.0.43.504).

 

Can anyone offer any advice?

 

Thanks,

James

[manu]

Hello!

 

What about removing the ci permission at the main branch instead of dealing with co permissions (that doesn't exist in Plastic SCM 5)? At the end of the day you want to preserve the main branch clean, right?

 

If they start working on the wrong branch and they try to commit an error will came up, but they are able to:

1) Create a shelve

2) Commit the change in a new branch.

 

With the usage of Plastic they will learn that the main branch is not for performing changes and the user-error will disappear in a short time.

[jimbo1999]

Thanks Manu,

 

My main concern is that if devs have access to check in on the SystemTest branch they'll not bother creating their own branches and simply check out and in from the System Test branch, which is something I want to avoid entirely. I'll try removing the ci permission and see how your suggestion of shelving works.

 

I'll admit I'm totally new to this style of working and it's taking a while to get used to it!

 

Thanks,
James

[manu]

Hi James,

 

alright in that case I'm sure you should deny the ci permission on that branch, that will force developers creating branches using the "Checkin in a new branch feature" or using "shelves" if they still edit at the SystemTest branch, at the beginning I'm sure you will have people using this two features when they get the permission error, but as soon as they notice working in branches is much better they will just create them!

 

Do you use any issue/task tracker? Like Jira... bugzilla...? It really fits with the "branch-per-task" methodology.

[Skreen]

Hi Mau,

 

I too think it would be good to be able to prevent co (check out) on the main branch. It would be better to get the warning when you initially perform the check out and not waiting to when you go to perform the check in. You have posted the work around of creating a shelve or checking in to a new branch, but it would be better to catch the mistake of working in the main branch at the start.

 

Thanks,

Damian

[jimbo1999]

Manu,

 

Sorry I only realised today that you replied to this post. I've done quite a bit of playing since I started and we've now decided that the SystemTest will be available to all developers to check into. This means they can work directly on the branch (which is the same system as we have now) or developers can create their own branches if they are doing something bigger and are comfortable with the branch methodology (I want to ease people in to the new way of working).

 

One question though - I tried to prevent people checking in directly to the System branch yet still being able to merge their own branches back to the System branch. It doesn't seem possibly because once the branch is merged a check-in is required to commit the files to the branch. Or am I completely misunderstanding how Plastic should be working?

 

Thanks,

James

[manu]

@Skreen

As can't be done with plastic due to that feature is present you can use the triggers system to complete it. I think you can create a before-clientcheckout trigger that checks if you are working in the wring branch, if it's the case show an error (make the trigger fails).

[manu]

@James

You are right, if you deny the ci permission for the "/main" branch, for example, developer won't be able to commit directly and neither from a merge operation, at the end o of the day it's the ci operation what you are denying and you need it to finish the merge.

 

There's an alternative and it requires some scripting, tell me if you are interested.

[jimbo1999]

Thanks Manu, I guessed that would be the case based on my playing around. I think we're just going to let devs have free rein on the System branch but have a specific admin login to allow checkins on the release branch. Thanks for the offer though.

[manu]

You are welcome, hopefully your developers will see that working on a branch is much better. Having the 'integrator' role also helps a loooooot.

[calbzam]

Hi,

 

To update this post, the triggers issue was related to use "before-checkout" triggers instead of "before-clientcheckout" . Actually, the "before-checkout" triggers don´t exist in Plastic 5.

 

Regards,

Carlos