Exclusive CheckOut of eSpace Items

On our radar
Hi guys,

Although I'm just starting working with Outsystems technology I find myself with several ideas in mind already. The first I decided to share however is the need to sometimes lock components from concurrent changes. When we are working on mission critical Actions or screens, and its a LONG development (4-5hs), you just know its best to let other team members know they cant edit that particular item. If we had a CheckOut Exclusive option we could make sure no merge conflicts arise later for any communication problem.


Created on 12 Aug 2010
Comments (9)
Actually the concept within the mentioned thread is quite different, its only a Comment based information about changes in the last version.

I am not talking about version control per-se, only that we should be able to LOCK a component from being changed by others in a given e-space. Lets say for example I'm working on a screen flow and I will be doing so over the next 2 days, to prevent concurrent changes by others I would lock that screen flow (not the entire eSpace) by checking it out (flagging it in the server as LOCKED) and the server would share that info with anyone who wants to commit changes to the checked out components and PREVENT them from doing it.

I dont think that this is mentioned anywhere in the comment thread of the provided link Evert. :-)
This is indeed not the same, only I think there is a similar idea to this one.

But it was by comments (I think) and not by screen locks. Don't know if screen locks is the right way to do so, because what if someone 'forgets' to set the screen lock off? Or go on holiday and forget to turn it off?

Do you make you delivery manager a 'super' user which can 'overwrite' the developer's lock?

Resolving that type of issue is typically done by providing an Admin user who can remove those locks at will.

Following on the industry standards (just check Visual SourceSafe or CVS to name a few...).

Locking something not to be changed by others is the ONLY sure way of resolving low-level change conflicts when working in a medium to large team environment where people work on the same components as their team mates.
There is imho no need for this.

A) The solution should be split up in multiple e-spaces, so there are not many people working on one espace at the same time

B) If person A wants to change an action that person B also is working on, then the workitem distribution is simply not correct.

However, I must say that the merge-conflict in OS is not superb.
The current situation is too simple, you collect the differences and show them as a merge-conflict. It should be more in a way, what have I touched in the oml, that is the only stuff there might be a merge-conflict, the rest is updated by others and should be merge implicitly.
Although you might not feel it necessary there are projects where by definition people need to interact with every webblock, screen, action and so on far too often. even if we split stuff  in multiple espaces if we are always dependant on centralized logic, we take the risk of more than one developer needing to update a given item at the same time without knowing.

In order to prevent that risk the OPTION for locking an item out is a must-have IMHO. Considering that OS is a platform used by so many already and growing fast it is required to have the foresight of anticipating this type of scenarios even if they are uncommon and providing a simple mechanism of counteracting the inherent risk factor.
Because you want to take the risk of creating workitems on the same action and having those workitems assigned to different developers you want the option to lock that same action.

I don't understand what the point is of having the them assigned to multiple developers. If it's locked, developer B has to wait or doing something else before developer A is finished.

If B waits, why has A not gotten  the workitem in the first place?

if B works on a different item, he has to merge anyways when he finally can work on the workitem, again, why the lock then?

I guess I'm still missing something, but I always hated the VSS-mechanism. Give me Subversion anytime :)
Sometimes the dependencies of objects might be intertwined so deeply that in the end you are using something someone else requires. If for example work items have been given in bulk and whatnot.
I'm not debating the architectural side of this problem, I'm just stating that a lock mechanism would allow for the development team to control and minimize the risk in such situation. And I also fail to see why an added security tool for application integrity
even if it is completely redundant in your typical scenarios can
be considered discardable when considering that the OS platform
is used by so many people.

In my development universe though, redundant features ensure
options that allow for safer development in unforseen environments.
I like this idea. It would be very helpful to me and my team members.