By Ricardo Casaca on 19 May 2010
Branching could be useful in different situations, some more relevant than others, but on big factories with a team with several developers, it could be very useful.

A situation that occurs frequently is when we receive a change request which requires changes on core entities, this will break the environment , and will affect other developers that are working on a different feature, but are prevented of testing/developing without pain since the environment is broken.
So it would be great of having an way of creating a branching per pta of a solution, were the developer could make the change that will break the environment isolated, finishes the development, could test it isolated again (remeber that i've mentioned a branch of the solution), if everything is ok, perform the merge of the branches, create a new solution and schedule the publish.
Im mentioning PTA was a way of doing it, it could be by branch, if it was possible to work on different espaces on a context of a branch

If i was a smoker i would quit smoking with this feature :)
J.19 May 2010

what about cloning?

will that not solve the branching?

Ricardo Casaca19 May 2010
Clone is a different espace, different id, which would lead to different entities (id's), and so on, so when you wanted to merge back of the original one they wouldnt match, and still i wasnt able of testing it. 
Im not seeing a way that clone could help in this situation, can you share what you were thinking?
J.19 May 2010
Well, branching in my book is branching the source code.
not the actual data. so with cloning would accomplish that.

so actually what you are saying is "branching" the whole application including the data.
that is imho, the idea of synchronizig dev/prod/quaility servers.

Ricardo Casaca19 May 2010
Yep, i want to branch the source code, use the same data, and dont affect other developers work that are working on a different branch. With cloning im not able to accomplish this.

it doesnt have anything to do with synchronizing DEV/QA/PROD
J.19 May 2010
But if you change the core entities, no matter what branch you are, it will effect the developers anyways, because the core data is changed in your case.

unless you want a clear copy of the developement environment, then my original thought that you should either

a) clone the relevant espac and bootstrap the data again
b) synchronize DEV/QA/PROD but more like DEV1/DEV2
or rethink your development street.

for example
1. DEV1: core entities
2. DEV2: other espaces + stable core
3. QA

or even think about the solution is organized.
frequent changes of core entities is imho somewhat strange.

Allow me to cast my vote in favour of branching eSpaces.

Yes, I get that that could cause problems/difficulties if the entities change and it wouldn't really solve the problem where developers must change the same actions, for different reasons (i.e. one needs to change it because it's part of a new development; another needs to change it because it's part of a bug fix).

However, branching would allow two things to happen:

1. Deloy just one branch -> suppose your development rules mean than you and only deploy new developments, and not bug fixes. Simply deploying the "development branch" instead of the "bug fix branch" would achieve this.

2. Simplify confict resolution -> since you know that what's on the "development branch" are all new developments, and what's on the "bug fix branch" are all bug fixes, merging both would be a bit easier because most bug fixes will happen on existing "code" and new developments are, well, new developments so there's less chance of conflict
Ravi Vakkalanka28 Oct 2014
I like this idea and looking for the same for a long time from Outsystems. I will describe my problem here and I think the original poster is talking about the same issue.

Suppose an espace - ABC having 3 Screens has been deployed into PROD. And a developer is creating a new screen # 4 in development environment for the same epace - ABC. In the mean time there was a bug identified in Screen # 3 functionality in PRODUCTION Environment and need to be fixed as soon as possible.  So is there a way we can migrate espace without having any of the new functionality of screen # 4 which is currently in development ?
Richard Tilbury12 Sep 2015

There would need to be some way of marking a version/ branch in dev to you can choose which code to work on - like the difference between dev and quality. Ravi's scenario is one which I'd like to be able to do more easily. At present we freeze code to our quality server and hotfix & release from there and apply the fix to dev at the same time. However, this doesn't work when we need to quality test a release! Having a dev server, triage server and quality is one way to go I guess!
Danny Prager1 May (3 weeks ago)

If you'r familiar with Git or Github you know what I mean. If not, here’s an explanation.

Casus: A colleague of yours “Citizen Developer” ha-ha. Made an app that works pretty well. Unfortunately he did not care about design, structure or future changes. Now the task is up to you to create new features in the spaghetti code he left behind. You decide to rebuild, refactor the app. This would result in a broken app that can only build again when you have finished refactoring his code resulting in a period where you are not able to perform hotfixes, maintenance or changes to the old application.

When branching is possible you could simply create a new branch from the current application and work on that when refactoring over a longer period of time. If anything goes wrong with the current application you can fix it without any worry’s. When the time for publication of the refactored branch  is ready you can merge it with the old branch and publish it to the webserver.

Merged from 'Make branching an application possible' (idea created on 2017-05-01 09:18:22 by Danny Prager), on 2017-05-03 13:59:49 by Goncalo Borrega
Justin James2 May (3 weeks ago)

This is an often requested idea, duplicate of others.


Merged from 'Make branching an application possible' (idea created on 2017-05-01 09:18:22 by Danny Prager), on 2017-05-03 13:59:49 by Goncalo Borrega