Skip to main content
Completed

Block branch from accidentally mutating

Related products:Software Factory
Ester
Jeroen van den Belt
Erik Brink
Mark Jongeling
  • Ester
    Ester
  • Jeroen van den Belt
    Jeroen van den Belt
  • Erik Brink
    Erik Brink
  • Mark Jongeling
    Mark Jongeling

Recently we started working with the different branches for development, release and main. It is desirable that in principle (with the exception of hot fixes) all developments are carried out in the development branch.

Currently it is not possible to protect a branch against "accidental" mutating. Naturally, the developer should pay attention to which branch he makes adjustments in, but a mistake is easily made. And this means rolling back that branch and re-entering the work or a special merge action.
Of course we can introduce the "pastry scheme" for those who accidentally do this. But it would be more useful if we could secure the branch, for example by showing a notification when the branch is opened.

Is it possible to make such a adjustable warning for branches?

Did this topic help you find an answer to your question?

12 replies

Mark Jongeling
Administrator
Forum|alt.badge.img+23

Hi Marc,

There are a couple options I can think of in the moment. The most easy would be indeed a message when opening any menu item that the branch you are working in is a branch that should not be mutated. We used to have this when opening a Production project version but was lost due to the concept changing. Is this a suitable option?

A more impactful and less desirable solution is having context and layout logic on every editable screen in the Software Factory simply preventing the execution of any task and disallowing Add/Edit/Delete; but the downside is that you cannot change anything when it is needed.

We are open to hearing everyones suggestion 😄


Mark Jongeling
Administrator
Forum|alt.badge.img+23
NewNeeds feedback

Forum|alt.badge.img+7
  • Author
  • Captain
  • 55 replies
  • March 27, 2024

Hello Mark

The most ideal solution would be what you propose as the 2nd option.
But to avoid the "I wasn't paying attention and now I have to do everything again" mistakes, I think option 1 (showing a warning) is also a good step.


Mark Jongeling
Administrator
Forum|alt.badge.img+23
Needs feedbackOpen

Dave Bieleveld Starcode
Vanguard
Forum|alt.badge.img+2

The 2nd option would be the most formal and complete approach. (Aside using guard triggers on the sf db as the ultimate protection). When it can be implemented with a dynamical control procedure, it might be less work then it looks like possibly making it more desirable.


Mark Jongeling
Administrator
Forum|alt.badge.img+23
The following idea has been merged into this idea:

All the votes have been transferred into this idea.

Remco
Moderator
Forum|alt.badge.img+3
  • Moderator
  • 42 replies
  • October 11, 2024
OpenWorking on it!

Remco
Moderator
Forum|alt.badge.img+3
  • Moderator
  • 42 replies
  • October 16, 2024

Hi All,

In the 2025.1 platform version we introduced an option to set a branch read-only per user.


Remco
Moderator
Forum|alt.badge.img+3
  • Moderator
  • 42 replies
  • October 16, 2024
Working on it!Next release

tiago
Captain
Forum|alt.badge.img+5
  • Captain
  • 47 replies
  • December 2, 2024

Oh joy, is this really in the next release?! 
I know it's totally my fault, but the last week I'vee been literally been doing everything twice, because after a sync to the IAM, the MAIN branch is open and as there is no way of visually distiguishing DEV  from MAIN, I always forget to first switch back to DEV. 
This resulted in lots of time spent, and broken branches. Glad to see this will be soon of the past :-) 


Jeroen van den Belt
Administrator
Forum|alt.badge.img+9
tiago wrote:

there is no way of visually distiguishing DEV  from MAIN, I always forget to first switch back to DEV. 
This resulted in lots of time spent, and broken branches.

Hi ​@tiago,

Then you might also find this an interesting idea to cast your vote on:

Perhaps you could repeat this use case for that idea there as well.


Jeroen van den Belt
Administrator
Forum|alt.badge.img+9
Next releaseCompleted

Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings