Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

It costs almost nothing to use the commit history maintained by the version control system. However, during a major project refactoring (or reorganization / cleanup) effort, functions and classes and even namespaces will be moved around; sometimes several files will be merged together and other files will be split. These changes often lead to the loss of the original commit history of a few files.

In my personal opinion, the up-keeping of the organization of the project is more important than keeping the source code history. Good project organization allows new features to be added continuously with reasonable effort, while the value of source code history appears to be dubious.

Furthermore, with the use of unit testing, regression issues are quickly identified. As long as the latest version continues to satisfy all of the software requirements, do we actually need to preserve the history of the source code?

I understand that any shipped source code must be preserved because of the need to provide support to the customers without requiring them to perform a major version upgrade. But aside from this, is there any value in keeping the history of source code commits?

Does source code commit history play any role in the communications between team members? What if we abolish the commit history, but instead rely on "source code" + "unit testing code" for communication?

Does the existence of commit history make one complacent about the long-term documentation of important information about the project, such as the major design/requirement changes and the streams of thought that drove those changes?

share|improve this question
3  
Depending on what source code system you use, the version history will be preserved even with file moves and whatnot. History for deleted files should still be accessible too. And in the end what matters is the history of the final result. Class X may be a combination of classes Y and Z, but history will tell you that (especially if you have good checkin comments), and you can still trace back to the originals. Am I missing something here? –  Anna Lear Jan 24 '11 at 5:37
    
These changes often lead to the loss of the original commit history of a few files. Have a look e.g. at "git blame" - nothing gets lost. Sometimes it may be a bit harder to find, but it's always there. –  maaartinus Jan 24 '11 at 7:54

3 Answers 3

up vote 3 down vote accepted

To use commit history for more than "made changes" or "fixed bug" type comments, it should be linked with your issue tracking system. Every change, every commit, should have some issue associated with it so you know what changed, by whom, and why.

As long as the latest version continues to satisfy all of the software requirements, do we actually need to preserve the history of the source code?

Sufficiently complex software rarely has all requirements implemented and all bugs fixed for a multitude of reasons, so I think your assertion here is, let's say, optimistic.

Suppose you are on version 7.8 of your program. But you are supporting, in the field, 12 different active versions, like 1.6, 2.2, 2.8, and so on. Each of these aren't going to be upgraded to the latest version for a variety of reasons, so you are supporting all with bug fixes. A customer finds a bug in your latest 7.8 release. You fix it in 7.8. How do you know how many of the other releases need to be fixed? Without source history and issue tracking you don't.

share|improve this answer

As long as the latest version continues to satisfy all of the software requirements, do we actually need to preserve the history of the source code?

But aside from this, is there any value in keeping the history of source code commits?

Yes to both. It can be useful to know when something was changed, by whom and why. If you lose your history, your ability to do this is impacted.

Does source code commit history play any role in the communications between team members? What if we abolish the commit history, but instead rely on "source code" + "unit testing code" for communication?

Yes it does. The "source code" + "unit testing code" only approach doesn't tell you who / when / why.

Does the existence of commit history make one complacent about the long-term documentation of important information about the project, such as the major design/requirement changes and the streams of thought that drove those changes?

I suppose you could say that it does. But few developers ever thoroughly document the changes in requirements / design. And certainly almost nobody records the stream of thought that drove the initial development, or the subsequent modifications. Having the commit history (and especially the commit log messages), and crosslinks to the issue / bug tracking system at least provide you something to go from. And that's better than nothing, or a set of release snapshots.

share|improve this answer
    
+1 Also, relying on code for communication means that information that would be in the history is also present in comments, violating DRY. –  Larry Coleman Jan 24 '11 at 14:06
1  
@Larry - true. But in reality, the problem is likely too little information recorded rather than too much (or duplicated) information. –  Stephen C Jan 25 '11 at 4:16

the value of source code history appears to be dubious.

I've had engineers go back several years into source code looking for answers to why something is the way it is. Sometimes the way things have evolved over time is important to understanding a bug, but it is not something that is typically thought of when documenting things (nor even necessarily documentable).

Also, there may be very good legal reasons for keeping source code history. Most source code dumpster-diving that I've had to do (as a build/SCM engineer) has been at the request of my company's legal department.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.