4

I don't know if I touch a delicate subject here, at least it doesn't seem to be easy...

There are many VCS out there, plenty more posts/blogs/... describing how efficient they are. And there are also many suggestions to remove stuff from the code when it isn't needed (clean code). There are always sentences like "it doesn't get lost anyway", "you can always get back to it", ...

I can't quite follow that. Let's say there a few developers working on one particular project. New requirements appear on the scene resulting in creating, modifying and deleting code. And hopefully refactoring.

In reality it happens occasionally that a certain feature is required, then dropped and then re-added later. In other words there was code written already. That code got written during the "required" phase and got removed during the "not any more" phase. What happens in the "re-added" phase? Some may suggest to rewrite the code, but I don't consider that an option here. Actually the "old" code might include fixes for problems that arose back then.

The project isn't small, many classes, plenty of logic, maybe some personnel changes, you get the idea. IMHO it's not fair to always expect from at least one developer to remember that there was code written and where it happened (including branch names).

Is there any support from a VCS to answer questions like

  • Where was a yet removed particular method and I only have a vague guess about its name?
  • I'm pretty sure that there was an if-statement right here, but what happened to it?
  • ...

I don't want to restrict this question to one VCS. It should be more of a general question. If anyone cares, we currently use Mercurial.

sjngm
  • 12,423
  • 14
  • 84
  • 114

1 Answers1

0

This is the kind of scenario best handled with:

  • many feature branches
  • one consolidation branch in which you are merging (or reverting if you don't want anymore a feature merged) all the features that should make it for the next release, in order to perform integration tests.

(as described in "What is a useful Branch Versioning Strategy?")

This is easier to do with DVCS (Mercurial, Git), in that you can easily merge/rebase/cherry-pick a set of commit from one branch to another, but also canceling commits you don't want to see.

Now about "finding stuff":

Since revisions in a DVCS tend to be smaller than in a CVCS, you end up with the "small things" isolated in their own commit that you can get back later and see if they have been merged or not.

What is also easier with a DVCS is:

  • keeping a clear history with coherent change sets (since you can re-arrange commits, splitting them or merging them together), which improves the change of getting back a particular modification isolated in a well identified commit (and not mixed with other changes in the same revision),
  • finding a specific content within commits.
Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks, but that doesn't answer my question. I was asking about _finding_ stuff in a growing code base. A lot of code is committed into various branches, gets merged or not, so the chances are high to lose the small things out of scope. – sjngm Feb 14 '12 at 06:39
  • @sjngm: ok, I have edited the answer and added a section more relevant to your question – VonC Feb 14 '12 at 06:50
  • 1
    I see. The `git log --oneline -S` [you mentioned](http://stackoverflow.com/a/7909283/483113) seems to do pretty much what I'm looking for. The [docs](http://linux.die.net/man/1/git-log) say that `-S` also lists results where the string disappeared. Neat feature. – sjngm Feb 14 '12 at 07:23