What arguments exist against keyword substitution as a feature in version control systems? [closed]

开发者_StackOverflow社区 As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 12 years ago.

Are there any arguments out there against keyword substitution (i.e. replacing $Revision$ with $Revision: 5$) as a feature in version control systems?

I'm not looking for a debate. I'm looking for well thought-out arguments by people who think the feature is a bad idea.

Here is one such argument:

• Keyword Substition: Why You Don't Need It

It's succinct, and I think the argument about the problems it causes for binary files is cogent, but I don't find it compelling.

Again, I'm not interested in a debate, just good arguments agains the feature. I can make up my own mind, but want to have good data with which to do so.

---

I'll admit that it's been very many years since I used keyword substitution in a version control system.

The really hard one to justify is $Log$. It seems like a good idea at first, but after a short while it really starts to clutter up the source. The information is easily available from the version control system when needed, so having it in the file is redundant.

---

Well, what arguments do you have for it?

If you need any version information: "who changed what, when, and why?", ask your repository.

If you have source trees where you can't tell which version they are, or even source trees with files from different versions, you might be doing something wrong (meaning: I can't see a use case that justifies this.)

In addition the information may be plain wrong. When I fetch a file from the repo, and edit it, the header will still say "this is revision 124". It's not. Only your repo can tell you "this file differs from revision 124 by the following changes:".

---

I've used CVS only during a brief stint, when all this version-what?? stuff was rather confusing anyway. We've moved via VSS to GIT, and I've never missed it.

(I do remember that it seemed to be important for CVS.)

---

One argument against is what the article you link to calls a "binary integrity standpoint": When comparing files from two different revisions, you'll get a lot of false positives because of the changed revision stamp.

Also, when updating a working copy in a project that uses keyword substitution, every file will have to be updated, which can be expensive traffic-wise and otherwise (e.g. if you're doing a live mirror of your working copy or something).

I don't really see much of a problem in this, though: If the side-effects of keyword substitution are going to be a problem for your project, simply don't use it. All in all, I think it's a great feature.

---

It is a confusing feature, because it causes the "real" content of the file to be different from what you get in your working copy. This leads to the following questions:

• What happens if you edit the substituted text in the file and commit. Will it result in an error on commit? Will it replace the original keyword in the "real" file? Will the change be ignored?

• How do you edit the keyword in your working copy? After all, you can't see it any more in the file - it has been substituted.

After reading how it works in subversion, the answers are not at all clear to me. I would have to try and see to be sure. To me, that's an indication that this feature is more trouble than it's worth.