View RSS Feed

Development Team Blog

Source Control and Visual DataFlex 102: Multi-Developer Use

Rate this Entry
Source Control and Visual DataFlex 101: The Basics got you started with source control.; this post will show you how to use source control when multiple developers work on the same project. This post builds on the previous post and assumes you are familiar with the information in it, so if you have not, please read it now.

Just as the aforementioned post, the purpose of this post is to allow you to start using source control in a fast and efficient manner. It is not intended to explain every term or every possible use and technique of source control. There is lots of information on the web and there are many books available on this subject.


Things get a bit trickier when multiple developers work on the same project. The main issues are:

  • How to keep code changes by all developers working on the same workspace/project from overwriting each other.
  • How to keep code changes by all developers working on the same workspace/project from breaking each other's code.

There are multiple strategies for dealing with this. As discussed in The Case for Source Control, we use Vault in CVS style (edit, merge, commit). Summarized very broadly, each developer working on the same workspace has a local copy of the workspace. Before we start working, we perform a 'get latest' action, which refreshes our local copy with all of the latest changes to the workspace that anyone else has checked in. Then we make our changes and check those in when we are ready to commit (meaning that the code compiles and won't break the workspace for anyone else).

You or your team can create your own rules for this. For example, we never check in anything that is not self-contained and running. Depending on what you are doing and where you are in the development, cycle check-ins may occur monthly, weekly, daily or multiple times a day. Your source control strategy can be customized to suit your needs and preferences. Modern source control systems are flexible enough that they can be configured to work the way you want them to work, which can mean minimum changes on the developer's part.

Getting a New Developer Up To Speed

So, let's take a look at a sample scenario where "Fred Tester" joins the development team for the Order Sample workspace that in Source Control and Visual DataFlex 101: The Basics his colleague Dennis worked on. For this scenario, I've added another user to Vault, logged into Vault with this user account and selected the 'source control blog' repository. I've set the working folder to a different folder (a blank one) to simulate what Fred would have to do to get up and running on his local PC. When Fred views the files in the repository for the Order Sample, the Status column for all files shows "Missing", since he does not have a copy of the workspace yet.

Name:  FredInitialValutState.jpg
Views: 962
Size:  54.8 KB


So, Fred right-clicks on the Order Entry folder and selects Get Latest Version... from the context menu. In the Get Latest Version dialog, he selects make all files writable and clicks Ok.

Name:  FredGetLatestVault.jpg
Views: 746
Size:  29.1 KB


After the latest set of folders and files is checked out, all local and remote versions match up and Fred knows he has the latest because he can see that Customer.vw is at version 4, which includes all the latest changes committed by Dennis. If Fred views the history of Customer.vw, he sees the same list of changes Dennis sees.

Name:  CustomerVWHistoryAfterRollback.jpg
Views: 942
Size:  88.1 KB


Second Developer Commits Changes

Now Fred gets to work. He opens Customer.vw in Visual DataFlex Studio. He cuts the E-Mail Address dbForm from the Address tab and copies it to the new tab that Dennis added. While he's at it, he renames that tab's label to "E-Mail" and its object name to oEMail. Then, he opens Invt.vw and resizes it to be just a bit larger just because he likes it. Next, he compiles and runs the program to make sure his changes work as intended. Now he's ready to commit the changes.

As before, Vault has detected the changes Fred made and listed them in the 'Pending Change Set' tab. If he sees any changes he's not sure about, he can right-click on them and review the differences between the current repository version and the local working copy of the file. He sees that all the changes listed are correct and commits them, adding the comment "Added Email tab to Customer.vw and resized Invt.vw.".

First Developer Gets Code from Second Developer

After this, when Dennis checks Vault, he notices that 3 files display with a status of Old, so Vault has detected that someone has checked in changes making his local working file copies outdated. When he views the history of Customer.vw, he sees the change and comment Fred added.

Name:  CustomerVWHistoryDennisFromFred.jpg
Views: 667
Size:  58.1 KB


He could now perform a Get Latest action and get Fred's changes, then keep working on his workspace.


Now, what happens if Dennis had already been working on the same workspace and made changes of his own? Well, it depends. If he had made changes to different files than Fred, each could simply get the latest version of the files the other developer changed from the repository and keep working. If they both made changes to the same file, it gets iffier. Let's do something simple to test.

Dennis will leave the changes Fred made in Vault for now and make another change to Customer.vw in Visual DataFlex Studio. He's going to add another tab page. After he saves, Vault has changed the status of Customer.vw to "Needs Merge". The Pending Change Set tab displays the same status. If you do a diff of the the pending change now (repository vs working file version), you can see that most of the changes are different enough that the merge tool should not have a problem, but some may confuse it.

Name:  CustomerVwNeedsMergeDiff.jpg
Views: 803
Size:  259.7 KB


Vault has numerous ways of dealing with a merge. To let Vault attempt to automatically merge the files, perform a Get Latest action on the file and select Attempt automatic merge. Afterwards, you will have to carefully review the changes to make sure both developers' changes correctly made it into the merged file.

It can get quite tricky and tedious if this happens a lot or on many files. This is why we typically employ the strategy of avoiding this situation. It's pretty rare that multiple developers work on the same project and exact same files at the same time. In the rare circumstance where it does happen, I try to manually merge the files using Beyond Compare outside of Vault; by doing so, I know I have full control over the code. Once merged, I check the merged version of the file(s) into Vault.

Comments