Who we are

We are the developers of Plastic SCM, a full version control stack (not a Git variant). We work on the strongest branching and merging you can find, and a core that doesn't cringe with huge binaries and repos. We also develop the GUIs, mergetools and everything needed to give you the full version control stack.

If you want to give it a try, download it from here.

We also code SemanticMerge, and the gmaster Git client.

Working on a single branch- update-merge explained

Wednesday, February 22, 2012 Pablo Santos , 0 Comments

While our recommended pattern is definitely “branch per task”, sometimes you’ll find yourself sharing a branch with another developer or even the whole team. This post will explain the two common situations and how Plastic SCM solves them.

Scenario 1- Working on the same branch without conflicts

Suppose you’re working on your branch, you check the branch explorer and you see your situation is like this:

You actually have some changes pending to be committed and you just continue working on them. Your changes are:

Meanwhile, another developer ends up with his changes that don’t collide with yours, and later decides to checkin:

Now you go and check your branch explorer and see that now you’re “behind the head” of the branch:

If you now try to check-in Plastic will warn you telling that you might have conflicts:

You can go and check the changes of this last cset and since you see they do not conflict with yours, you can just go to the root of your workspace and run an “update”.

Plastic SCM will detect that your changes do not collide with the new branch head and will be able to move you to the new head, downloading the new changes. You’ll be again synced with the head and ready to checkin without merge:

Scenario 2 – Synchronizing colliding changes

Let’s go back to the beginning: you’re working on your branch and modified the following files:

At the same time your colleague modified the following:

Ok, the two first files are colliding!

Your colleague now is faster than you and checkins his.

So now your workspace is behind.

You try to checkin and see again the “merge needed” dialog:

Please note that the merge-needed dialog brings you the option to start a new branch, which is really convenient!!

You can press “Ok” and merge, or you can try to update your workspace as you did before. Now, if you try to update the workspace, since there are colliding changes, the system will warn you:

And the following merge dialog will show up:

You finish your merge (hopefully you do not have tough conflicts to solve :P) and then go back to the branch explorer to check what happened:

You see there’s a “merge in progress” pointing from the head of the branch to the changeset you’re working on (calm down directed-acyclic-graph purists... this is just a way to show the merge in progress and most likely we will modify it to render the “in progress” changeset too!!)

Now you’re ready to checkin and once you do it you’ll get:

So you’ve created a “sub-branch” (branch within a branch) without even noticing it! :)
Pablo Santos
I'm the CTO and Founder at Códice.
I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
And I love simple code. You can reach me at @psluaces.

Pablo Santos

0 comentarios:

Subscribe to: Post Comments (Atom)