Issue 20: Automagic source revision tags like $Id$, $Revision$, $Date$, $Author$

Reported by Unknown User, May 2, 2005

(This entry was imported from the savannah tracker, original 
location: https://savannah.nongnu.org/bugs/index.php?12937)

Okay, summary is a bit overoptimistic, I believe it is generally not 
expected that MT could come up with sensible and useful revision or 
version tags (numerically incremental at least).

I wonder whether it's possible to have $Date$ and $Revision$ though. 
Revision could contain MT revision SHA1, and Date would obviously 
contain date of last checkout or update.

These obviously doesn't have any use if the source file is being 
tracked by MT, but they became extremely useful when the source 
leaves version tracking. Since MT cannot come up with meaningful 
(incremental) $Version$s, $Date$ and $Author$ could be the best help 
to be able to tell that the untracked source is at which version, or 
actually whether SourceA is newer than SourceB.

I know, parallel developent makes it non-trivial to decide whether a 
file is newer than the other, but humans are pretty good at 
guessing, so I could guess that a file with a year old timestamp may 
be older than the one dated yesterday, no matter how warped the 
development graph is. :)

What I don't know how MT would handle this, since expanded macros 
change the SHA1 of the files, but I guess it is handled similaryly 
in every SCM: convert to general form before work and expand it 
[again] afterwards.

Would be very handy for releasing MT tracked source to the public by 
non-MT means...


monotone version:
-----------------
0.18, probably doesn't matter anyway

Comment 1 by Unknown User, May 2, 2005

I wouldn't hold your breath on this one; this information is easily 
obtainable other ways (note that monotone itself always knows what 
revision it was built from, without any use of $$-keywords), and we 
really really don't like munging files when we can help it.  
Monotone tends to treat your data as sacrosanct, unless you _really 
explicitly_ ask it not to.

Comment 2 by Unknown User, May 2, 2005

About MT I don't plan to hold my breath anyway. :)

About MT knowing itself: I give you two lua.cc files, and you get 10 
seconds to tell which is newer. :) [Actually it would be fair to 
give you two files from a project you're not involved in.]

This is not about _a whole project_ but about source files. Natually 
it is possible to find out whether a file is 2 years old or 2 days 
old, but it may require unacceptable efforts. And programmers tend 
to forget to update changelogs, version numbers and dates in files 
(at least *I* tend to forget). Imagine, for example, monotone 
distribution in tgz containing a contributed perl script to create 
whatever, and this perl script is available 23 different ftp sites. 
Is the one in monotone fresh? Or is it actually 4 years old? How 
could you tell, since monotone "knows" that it is 0.18 
27653615352352153521351, but this doesn't help...

The whole reason of me wondering because I supposed that MT treats 
files as holy material and try not to change. But I know no other 
means to keep track of the version of the released sources. But 
maybe I am the only one in the world having this problem of wanting 
to identify sources?

Still, I accept if MT deny to do that, but I wanted to hear some 
input on it. No harm taken.

Comment 3 by Unknown User, May 3, 2005

"I give you two lua.cc files, and you get 10 seconds to tell 
which is newer."

This question is ill-posed -- the answer might well be 
"neither".

I'm not quite sure I understand your use case here, either.  If the 
script is only modified by people using version control, then yes, 
the one in monotone is fresh.  If it's modified by people not using 
version control, then they're not going to update the $$-keywords 
either.  Where in this do the version control keywords help you?