Avoid copying source files around

PDF Print E-mail
Written by Graham Stoney   

Any time you dive for the cp or copy command on a source file, or go to drag and drop one in your file explorer, alarm bells should go off warning you to think about what you're doing.

One of the most common causes of changes by one developer being inadvertently overwritten or reversed by another is when source files are being copied around willy-nilly. In virtually all cases, you should use your source code control system to do this dirty work for you.

The best SCM system in the world won't save your ass if you go doing things behind its back and don't use it properly. Here are some common scenarios where developers copy source files around, and why it's a bad idea:

Another developer has the file I need to modify locked

You want to edit a file as part of the change you're working on, but someone else has it locked. So you take a copy into another directory or with a slightly different name, change the file from read-only to writable manually, and start editing away. You plan to merge your changes in with theirs later when you copy it back, but for the time being you just want to go ahead because your change can't wait.

If you do this regularly, you are certain to end up copying the file back over someone else's work at some point, if not now, in the near future. I've seen this happen countless times, and you end up wasting more time than what you '”saved” by this juggling act. The solution is to use a source code control system that supports copy-modify-merge so you don't run into other developer's locks in the first place.

Building on a new platform

You want to do a build on a new platform, so you copy your whole source tree across and do the equivalent of a “make clean” and “make all”.

You've just missed a golden opportunity to check that everything in your source tree necessary for a clean build is really in your repository. You also have no easy way to commit the changes needed to get it to build on the new platform; unless you're planning on copying the modified files back to the previous platform – and you aren't paying attention. A better approach is to install the client for your source code control system onto the new target platform and check out a clean workspace for the build there.

The new file is derived from the old one

If this really is true, then your source control system needs to be informed about it so that the history of the file is accessible and other developers can follow what you've done. Use the relevant command to your source control client to perform the copy/branch or whatever it is you're trying to achieve.

It's OK; I'll be quick; it won't take long

Perhaps not, but I guarantee that anything you do behind the back of your source control system will eventually come back to bite you in the bum, and you'll waste more time that what you would have if you'd followed best practices. If you still don't want to take this advice, just don't hire me to fix your problems when you come unstuck.



Social Bookmark this page:Reddit! Del.icio.us! Google! Live! Facebook! StumbleUpon! Spurl! Yahoo! Ask!
 

Add your comment

Your name:
Your email:
Subject:
Comment:

Sponsored Links