Merge code changes without true source control

Question

We have a few developers working on the same VS2005 solution, but our source control is very bad. (Our company uses Harvest, which we give a vote of no confidence).

Right now, we're all just working off of the files on a shared lan drive. Obviously, this causes some problems. But we think it's better than working locally, and tracking the files we touched in a spreadsheet and merging everything manually. Does anybody have a strategy for merging our changes?

Some of the problems exist because of corporate beaurocracy (like mandating Harvest). Those same policies prevent introducing new tools into our environment. So, strategies that avoid buying/downloading new software would work best for us.

Answer 1

Treat the share as if it were your source control system. Make the share read-only, which will force developers to get local copies in order to make changes. You then have a somewhat stable version to compare against. This would help facilitate being able to do "merges". "Checking" code in would have to consist of some sort of backup strategy for the file (possibly making a copy of the file with a timestamp and username as part of the new file name) and replacing the original with the new version.

That being said, doing this type of activity without a real source control system that is reliable is going to be difficult and error-prone.

Answer 2

You're probably going to have to download something unless you want to do it by hand. I highly recommend Winmerge. It's free, open source, and probably better for you a small download that doesn't mess things up.

Answer 3

Get git and install it locally on every dev's machine. Then set the repositories to replicate.

Answer 4

There is a standard unix command-line tool called merge that will fairly intelligently merge two sets of changes to a file. The syntax is:

merge mine older yours

Where "mine" is the file with your changes, "older" is the original file, and "yours" contains someone else's changes.

Not sure if you have a UNIX (or Mac OS X) box lying around to do this on though.

Answer 5

Working off of a shared drive is not a good idea, and gets my vote of "no confidence".

It would be too easy to overwrite other's changes, you have no change tracking, no way to branch or tag/label, etc.

Answer 6

This might not be a viable option, but perhaps you could use a distributed system like bazaar, git, or Mercurial.

The reason I suggest these is that they are very low overhead and can be used with other systems. I know with bazaar the repository is simply a hidden folder added to the directory.

Answer 7

Learn to use Harvest. It takes a little effort to get things going smoothly but overall it is an excellent source control system.

Answer 8

Another possibility would be Beyond Compare from Scooter. It has two and three way merge and great diff functionality on files and directories. If you want to know a little more about it, listen to the delphi podcast by Jim McKeith.

But like most others I would recommend to either use Git or learn Harvest.If the source control system allows to change its diff application, Beyond Compare would be an excellent replacement.

Answer 9

There are two distinct issues: version control and merging. There's absolutely no excuse to NOT use a version control system. If the company has decided on a solution (for whatever reason), then use it. Not liking it or not "having confidence" in it is not a valid reason for not using it. And using a shared drive to mimic a source code control system is beyond crazy.

Merging is a second issue. You simply need a diff/merge tool. Pick one. How have you gone this long without one?!

Araxis is a great one. Costs a few bucks. The SourceGear folks have been freely distributing their diff/merge tool for some time (the one that comes with Vault). It's also a solid contender. Those are two that I've used that I know are still on the market now. There are others some already have mentioned.

Merging everything by hand is not a tenable solution. Combining that with not using a VCS is a recipe for disaster.