Jump to content

Protecting the main branch from accidental check-ins


marioo

Recommended Posts

I was wondering how to protect a repo's main branch from accidental check-ins. Before I start a new task, sometimes I forget to create a child branch for it, which later causes accidental check-ins into the main branch. It may have bad consequences when somebody starts working with such 'dirty' changeset unaware.

 

Trying to find a way to protect programmers from this kind of mistake, I tested what happens when I deny my user the ci permission on the main branch. I noticed that when I tried to check my local changes in, I wasn't allowed to do that (just as I expected). But I was hoping to be able to provide a different user's credentials at that point to continue. But instead, only a message box was displayed to me, telling that I have no permissions to continue. So I gave up with no more ideas...

 

How to protect the user from accidental check-ins into the main branch? Do you have a solution for that?

 

What do you think about adding a possibility to provide different credentials at any moment you try to do something you have no permissions to do?

 

Regards,

Mariusz.

Link to comment
Share on other sites

Hi,

 

You can configure branch permissions to deal with this scenario. If you are getting problems to change permissions, review if you are the repository "owner".

 

Once you have configured permissions, you can run "plastic --configure"  to log as a different user to check that the configuration went fine.

The command "cm whoami" is intereseting to check who is the plastic user in each moment.

 

For instance, you can deny checkin permissions in main branch to a group of users. The will only be able to commit in task branches.

 

Regards,

Carlos 

Link to comment
Share on other sites

OK, so you confirmed that my idea was correct - thanks :).

 

However, the thing is that when I deny check-in permission in the main branch, we will have to go through PlasticSCM client configuration wizard every time we want to integrate our child branches into the main one, right? Because the assumption of this scenario is that we normally have no check-in rights in the main branch and have to log in using different credentials to merge our branches.

 

IMHO this is time consuming and still unsafe. If we forget to switch back from the "integrator" to our "standard" user, the main branch will still be unprotected.

 

What do you think about the idea I suggested, that is asking the user for different credentials when they want to do something they have no rights to? This shouldn't cause logging in as a different user, but just performing the single operation as a different user.

 

Best regards,

Mariusz.

Link to comment
Share on other sites

Hi,

 

But one question? Are you both users working in the same machine (using the same Plastic client)? In my previous post I assumed you were using different Plastic clients so you don´t need to switch from "integrator" to "standard". My proposal was that one user can be the integrator(with checkin permissions on main branch) and the rest of users won´t have permissions to checkin in main branch. This way is not necessary to switch users.

 

You can add your suggestions to our uservoice system. Feedback is always well received:  https://plasticscm.uservoice.com/

 

PD: I have a script that clean "client.conf" credentials every time you run Plastic client,  and ask you to enter user and password (not sure if it helps in your scenario).

 

Regards,

Carlos

Link to comment
Share on other sites

That seems a reasonable solution to use Plastic SCM on two machines. Thanks for your reply. But out of curiousity I will post my suggestion on your user voice system as well to see what others think about it ;).

 

If it comes to the script, I think I prefer the idea with two separate clients, so it won't be necessary - but thanks!

 

Regards,

Mariusz.

Link to comment
Share on other sites

  • 6 months later...

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...