How should we tackle a big change in our application ?

Question

We have this huge application that has 18 projects in our source control (VSS).

Whenever we are working on small changes everything is fine because each developer has a set of few files checkout to himself and hopefully no one is going to need them until they are checked in (in about 4 to 8 hours)

But when we want to work on big changes a developer keeps so many files checked out for some days and make it hard for others to do their assigned tasks.

Here's a scenario for example: Last week we wanted to implement a feature that will fetch every list in our application using a paging mechanism therefore we should change UI , business and data access layer. There's a developer assigned to this task and she's checked out a lot of files and she's blocking other tasks.

Here's my question: How should we plan to develop this kind of features?

Answer 1

Switch to a better Version Control System. VSS suffers from design issues and its hard lock principles. Subversion is available for free and can be used for large scale application development. Branching and tagging are cheap operations and there is no hard lock.

Your company will definitively live better with Subversion. Try it out!

Server Easy to setup on what system ever (Windows/Linux)

TortoiseSVN Client for Windows that integrates within Windows Explorer

SVN Manual Read at least the first few chapters

There are many other alternatives but VSS is a pain in large scale development. As there is a better free solution available, why stick to a vendor?

Answer 2

VSS sucks, migrate to a real SCM, microsoft will probably help you seamlessly upgrade to TFS which doesn't have this problem. Or migrate to any one of FOSS SCMs like subversion, but the transition will probably be harder (but may be cheaper).

Answer 3

Use a version control system that works in merge mode (optimistic), not in lock mode.

Merge mode is optimistic is that it assumes changes will usually not be made in the same place. If it happens in the same place then it is usally easy to resolve.

An example of a version control system that can work in merge mode is CVS. It is outdated now, but others exist.

Answer 4

SVN is the answer to your problems. I have used it and its a breeze to learn/work with it. But there are a few new kids on the block. Try GIT. I have been hearing a lot about it althought havent had a chance to try it

Answer 5

If upgrading to a real VCS isn't an option right now, have the person doing the major feature download a local copy of everything and then make his changes outside of version control. Merge it all at once (over a weekend or something in case it gets complicated).

This doesn't help the developer who will need version control while making the "big changes"

Well, you do what you gotta do with the tools you've got. He could always install a modern VCS like git which works locally. Just check the entire baseline into git (minus history) and go.

Answer 6

Have you considered sharing and branching? Also, you can allow multiple checkouts with users who have experience. In your case of making a large application change, I suggest labeling then creating a branch. If something happens to "big changes", you will not the production version. You can make your quick fixes in the released code then merge them into "big changes" once it is ready. Check the help topic "Sharing and Branching".

Answer 7

VSS is just an old story, we use Subversion (server) and TortoiseSVN (client) now. (That's just based on our preference) By the way, migrating to other version control / source control - only - will not solve your team issue. The problem is about communication. If she can't communicate with the others and stay with her habit (working with a lot of files without checking them in), she will put your team down, you must let her know how to work with team using version control. If not, she will put you into "Merge" problems when using Subversion. ^^

Answer 8

You already got the advice about changing to a usable VCS.

Above that, you and the developers should train to break the big changes into smaller ones. I'd consider about 10 commits per day and full time developer a normal rate. It makes the locks much less painful.

The principle should be: make the smallest possible change that brings you toward your desired state and works (as in the software compiles and passes all tests).

In the case you sketched out. Adding a parameter to one layer, and changing all calls to that layer (possibly with a dummy value) would be one change. Actually using that value, would be another change.

This should result in much less files locked for a much shorter period.

Answer 9

Long-term, you'll want to migrate to another VCS. As others have mentioned, consider either open source or TFS if you want to stick with MS. (We use TFS, but I'm not going to sing its praises - it's OK.) As AMissico mentioned, branching will help with any VCS that supports it. Learning to use branching effectively is not trivial, and will require study and/or training.

Continuous Integration will also help. TeamCity is what we use, and it's relatively simple to set up. See FeatureBranch.