I would like to embed some version information on top of my source code file with information such as version number, author, and date of edit.
Is there a simple way to do this with Mercurial?
Asked
Active
Viewed 4,446 times
5
-
1The author is largely fixed when the file is written, isn't it? Unless you want it to be the last person to edit the file. That's quibbling, though. Generally, DVCS (and even some centralized VCS, such as ClearCase) avoid putting version metadata into files. So, for example, you can't easily get the last commit number that affected a file embedded into the file, nor the date when that happened. I still use an archaic VCS (more precisely, RCS) because I value that ability, and my release systems are set up around it. I've not switched to Git or Mercurial or SVN because of this. – Jonathan Leffler May 12 '12 at 16:58
-
2See also my [discussion](http://stackoverflow.com/questions/645008/what-are-the-basic-clearcase-concepts-every-developer-should-know/645424#645424) (or is that a diatribe) about 'Embedded version numbers - Good or Evil'. – Jonathan Leffler May 12 '12 at 18:02
-
possible duplicate of [File history: in the source or let scm handle it?](http://stackoverflow.com/questions/929824/file-history-in-the-source-or-let-scm-handle-it) – ChrisF May 18 '12 at 12:21
4 Answers
4
This has been asked a lot here on Stackoverflow and the short answer is: you shouldn't do it.
You don't want a file that changes with every commit it makes merging a nightmare.
Better options are:
- write the version string to a file on
update - have you build/deploy script run $(hg id) and put that into the build at that time
Trust me, revision strings in files is CVS/SVN thinking. It has no place in a git / Mercurial world.
Ry4an Brase
- 78,112
- 7
- 148
- 169
-
I disagree, it does. And even in SVN you have to enable it via a property explicitly. Which is quite different from CVS which has to be taught explicitly which files are "binary" by means of `cvs add -kb` or in the repo configuration. – 0xC0000022L May 12 '12 at 23:12
-
1Both CVS and svn make it possible to have some files in a working directory checked out at different versions. I can do `cvs co -r 1.1 a_specific_file`, so having a "what versions is this damn thing" makes sense in cvs (and svn). In Mercurial and git you can't have some files at one version and others at another version (and still have nothing to commit / clean status), so `hg id` is always sufficient to know what's in _every_ file. Just make your build / deploy system one notch smarter instead of polluting your source files. – Ry4an Brase May 13 '12 at 17:43
-
How would you add the version to a file on update? Is there a way to automate it? I'm using SourceTree. – felwithe Oct 03 '15 at 20:48
3
As comments and other answers mention, it is not a good idea to rely on CVS-like, automatically expanded, tags. Specially since you can extract whatever meta-information you need at any time and almost any granularity afterwards.
However, if you really need it (because your boss says so, for instance), the closest you can get is by making use of the keyword extension that comes bundled with mercurial.
Douglas Ohlhorst
- 139
- 8
C2H5OH
- 5,452
- 2
- 27
- 39
-
1Here's the "why you don't need it" page about the keyword extension: http://mercurial.selenic.com/wiki/KeywordPlan#head-2007fad6f31bf6f1f1b5c3d5b02e5c6225de3ec5 I'm pretty sure that was drawn from comments by Mercurial's primary author, who actively recommends against the extension. – Ry4an Brase May 13 '12 at 17:45
1
Yes it is possible, but you need to enable it. What you are asking for is basically the keyword extension. Be careful when enabling this the first time (read the section about kwshrink, kwexpand), because you wouldn't want the actual expanded keywords to become part of the revision history.
Douglas Ohlhorst
- 139
- 8
0xC0000022L
- 20,597
- 9
- 86
- 152
1
My favorite way is to use the hgversioninfo plugin. It generates a version.py file on the fly on "hg commit", "hg update", etc.
drrossum
- 614
- 6
- 10