This is my first post since starting my new job.  I've been a smidge busy, as they threw me in immediately on a high-profile project utilizing Microsoft Office SharePoint Services, and, well, my working knowledge of MOSS was somewhere between zip and zilch.  That's changed significantly over the past few weeks, and while I've been hesitant to call myself a MOSS developer, I'm certainly getting my bearings and starting to kick much ass.

One problem our team has run into several times is source code control.  Pretty much everybody on the team was a SourceSafe user and didn't have any experience with SVN.  I initially balked at this, because, well, SourceSafe sucks.  I advocated SVN every chance I got, particularly when SourceSafe would eat somebody's changes or we fought over file contention. 

As luck would have it, the company is in the process of standardizing on SVN, and, when our VSS repository became obviously too corrupt to be much use, the technical architect on this project caved to my requests and we switched to SVN.

The problem with this is, SVN's Copy-Modify-Merge paradigm can be confusing for developers who are used to Lock-Modify-Unlock.  We've had several occurrences of changes mysteriously disappearing, and, since I'm the de facto SVN expert on the team, it was left to me to reconstruct exactly what happened.  To avoid naming names and pointing fingers, I’ll illustrate with Alice and Bob…

Let’s start with a file.  We’ll call it Text.txt.  Text.txt looks like this:

Alice and Bob both did an update and now have Revision 1 as their working copy.

Alice makes some changes and commits them.  She removes the line “Baz” and adds “42” and “Don’t Panic”.  She commits her changes as Revision 2.

Bob, meanwhile, makes some changes of his own.  Working with Revision 1 as his base, he adds “Quux”

Before committing, Bob does an update and realizes he has conflicts.

Now, what I think happened, is Bob made a mistake while merging, and chose to accept his entire conflict block as the merge output…

Bob then marked his conflicts as resolved and committed this as Revision 3.

The problem with this is that it negates Alice’s changes – She removed “Baz”, and she added “42” and “Don’t Panic”.  The next time Alice did an update, she updated to Revision 3 and the changes she previously made in Revision 2 were missing.  SVN gets blamed, making Cam look bad for being such a vocal SVN supporter, when it was really Bob’s fault.  (The “making Cam look bad” part was a joke.  Smile.)

What Bob should have done was take a good look at the differences between Revision 2 and his working copy…

…and asked himself, “what exactly did I change in my working copy?”  In this case, Bob did one thing and one thing only: He added “Quux”.  So Bob has to assume that any other changes to the file were done for a reason.  Somebody wanted “Baz” removed, and “42” and “Don’t Panic” added.  It’s then incumbent upon Bob to ensure that only his valid changes are included in the merge.  The resulting file could have looked like this:

The moral of the story:

Copy-Modify-Merge (like SVN) is more powerful than Lock-Modify-Unlock (like SourceSafe), but, as Uncle Ben Parker told Peter Parker, “With great power comes great responsibility.”  When you merge and commit, you have some responsibilities to live up to:

Update frequently.

When you merge, be sure you are not removing someone else’s important changes, and that you are only merging in the changes that you made that are relevant. 

When you commit, always read the file list to ensure you are not inadvertently committing changes to a file you did not mean to modify.  Also, it helps to do a diff of each file in the file list to be sure you are only committing code changes you mean to commit.

Good luck!