TechNow Ep 26 - Source Control LIVE at Knowledge16

[Chuck Tomasi]

I just got confirmation that we're all set for Wednesday May 18 at 4:00PM on the second floor by the SMCC (social media) area. Come join steppek, dave.slusher and me (ctomasi) to learn about one of our favorite new Helsinki features - Source Control. This is a game changer for developers! More info coming soon on the "Ask the Expert" area.

Update (May 5, 2016): Date corrected. It's May 18, not May 21.

[Viswanatha Red3]

Hi ctomasi

Thanks for the reply.

However, I still have few doubts on usage of Global apps in new custom scopes.

In Helsenki, we cannot move application files like BR, UI Acitons/policies... from Global to private scopes.

In that case, if I had to make changes like deactivating or modifications, then I can make it   only in Global scope update sets.

So, how are we going to handle these type of situations for external source control ?

Regards

Viswa

[Chuck Tomasi]

The best practice is to deactivate the existing BRs you don't need/want or conflict. As you noted, this is done in the global scope using update sets. No change there.

Going forward, if you want to extend the functionality of incident, problem, change, etc. make copies of the deactivated BRs, client scripts, etc. in your scoped app. Now you can manage them with source control, use the publish/install method of promoting them to other instances, uninstall, etc.

Hope this helps.

[Viswanatha Red3]

Hi ctomasi

Would you please help me how to handle the below scenarios :

Scenario 1:

• 3 Developers are working on the same application in one Dev instance and every one on master branch
• Each developer started making individual changes as part of their user stories
• Dev2 finished his user story and wants to commit, When he committed, all the changes (along with Dev1 & Dev3) changes are also committed into master branch.

        Q) How to restrict to commit only Dev2 changes instead of all changes ?

Scenario 2:

• Release 3 is in production and has a bug
• Dev instance has changes related to Release 4
• One developer creates a branch from existing Release 3.(say 3.1)
• Now the rest of the developers cannot work since the app branch is changed and have to wait till the developer fix the bug and revert to main branch.

        Q)     Is there any possibility to lock the branch to only particular user ?

        Q)   How to move the changes from bug fixes branch 3.1 to release 4 ?

Thanks & Regards

Viswa

[Chuck Tomasi]

Hi Viswa,

The answer to question 1 is that everyone is working on the same branch at the same time. It is not user specific, it is system specific. Think of the source control as a way to manage the app, not individual user's work on that app. It commits everything as a 'snapshot'. You do not pick and choose which elements get committed.

The way to move your changes from 3.1 to release 4 is by stashing them. You can then apply the changes in the stash to the new branch. See the section of this video that discussion stashing.

Hope that helps.

[Viswanatha Red3]

Hi ctomasi

Then I would see that it as a potential problem to implement Source control for multi user development on single platform.

Prob1: When a user tag as mark of his end of User strory, the changes consists of other developers also. Tagging makes no sense

Prob2: If a developer takes 1 day to fix a bug on different branch, then other developers has to wait till the developer completes his job.

Prob3: I cannot stash my own changes instead I end up stashing all developers work. During multi user development, the changes would be in 100s. I cannot pinpoint exactly what are my changes and commit to other branches.

This feature only works with one developer.

Are there any plans of resolving these issues in coming releases ?

And do you have any strategy to make it work for multi user on a single platform ?

Regards

Viswa