How can the Eight Commandments of Source Code Control be modernized?

Question

How do you update this? I've never seen any current team that actually "checks out" a file. I don't compile, either. These seem to be from before the days of branching.

1. You shall check in early and check in often. You anger your coworkers when you check out a file and insist on keeping it checked out until some future point in time that is measured using variables that exist solely in your brain.
2. You shall never check in code that breaks the build. If your code does not compile, it does not belong in the source control repository.
3. You shall not go home for the day with files checked out, nor shall you depart for the weekend or for a vacation, with files checked out.
4. You shall leave a descriptive comment when checking in your code. You need not include your name or the date in the comment as that information is already tracked.
5. You shall use the 'Undo Checkout' option if you check out a file and do not make any changes. It displeases your coworkers when you check in code that has not changed at all from the original.
6. You shall not use comments to 'save' defunct code. Fear not, for the code you delete still exists in the source control code history and can be retrieved if needed.
7. You shall use source control for more than archiving just code. The source code control repository makes an excellent storage for technical docs, SQL scripts, and other documents and files related to the project.
8. You shall religiously backup your source code control database on a regular basis and store a copy in an off-site location.

From http://scottonwriting.net/sowblog/posts/13581.aspx

Answer 1

What is there to "modernize"? I don't see anything that relates to COBOL or Ada...

Answer 2

Why would they need to be modernized? They look just as relevant now as they were on the day they were written, IMHO.

Answer 3

Since most modern source code control systems allow the possibility of concurrent checkouts, I can see where (3) could be relaxed, although it's still a good idea to check in at night so that it gets backed up. TFS allows you to shelve pending changes so you could save your changes without really checking them in when your code breaks the build but you want to check in before you leave at night.

Answer 4

Whether you do checkouts or not depends on the VCS (Version Control System) you use. If you use SCCS (old school, but part of the Single Unix Specification), or if you use Atria ClearCase (from IBM Rational), then locking checkouts are a part of life. With more modern systems, when you create a working sandbox, you effectively do a checkout, but it is a non-locking checkout that does not prevent others from making concurrent changes from the same starting point.

You say you don't compile...I bet your code gets read by some program and then acted on. Perl doesn't have a separate compiler per se, but it does have a compile phase. Shell scripts are read and validated. Likewise Python and Ruby. The modern form of the rule would perhaps say:

• You shall never checkin code that is not acceptable to its language processor, whether that be an interpreter or a compiler. If your code is not at least syntactically correct, it does not belong in the main branches of the source control repository (though it might belong in your private working branch).

Item 3, about not leaving code checked out, remains substantially valid. If you hold code in your sandbox for protracted periods of time, then you are making your own life more difficult as you will probably have more merging to deal with because of others who have worked on the same code while you had it in your private branch.

All the other points seem as valid under Git or SVN or CVS or ... as they are under SCCS or ClearCase.

Answer 5

Continuous Integration.

1. Maintain a Single Source Repository
2. Automate the Build
3. Make Your Build Self-Testing
4. Everyone Commits Every Day
5. Every Commit Should Build the Mainline on an Integration Machine
6. Keep the Build Fast
7. Test in a Clone of the Production Environment
8. Make it Easy for Anyone to Get the Latest Executable
9. Everyone can see what's happening
10. Automate Deployment

Answer 6

You shall not go home for the day with files checked out, nor shall you depart for the weekend or for a vacation, with files checked out.

You shall use the 'Undo Checkout' option if you check out a file and do not make any changes. It displeases your coworkers when you check in code that has not changed at all from the original

You shall religiously backup your source code control database on a regular basis and store a copy in an off-site location.

If you have to worry about any of these, your SCM is full of failure. Get a better one.

The rest of these are pretty good ideas...

Answer 7

updates for the year 2008.

1. You shall commit early and commit often. You anger your coworkers when you break the build in the main branch.
2. You shall never check in code that the build-bot doesn't accept.
3. You shall not go home for the day without merging your branch with others'
4. You shall leave a descriptive comment when checking in your code. You need not include your name or the date in the comment as that information is already tracked.
5. DELETED!
6. You shall not use comments to 'save' defunct code. Fear not, for the code you delete still exists in the source control code history and can be retrieved if needed.
7. You shall use source control for more than archiving just code. The source code control repository makes an excellent storage for technical docs, SQL scripts, and other documents and files related to the project. You can even use source control on your OpenOffice Documents using the SVN plugin
8. You shall religiously mirror your branch on a backup server.