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?