bugmonotone - Bugs: bug #12937, Automagic source revision tags...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #12937: Automagic source revision tags like $Id$, $Revision$, $Date$, $Author$

Submitter:  Peter Gervai <grin>
Submitted:  Mon 02 May 2005 04:24:17 PM UTC
   
 
Category:  working copy Severity:  3 - Normal
Item Group:  feature request Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open
mtn version --full: 

0.18, probably doesn't matter anyway

Mon 02 May 2005 08:04:02 PM UTC, comment #3: 

"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?

Nathaniel Smith <njs>
Group Member
Mon 02 May 2005 07:27:36 PM UTC, comment #2: 

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.

Peter Gervai <grin>
Mon 02 May 2005 05:33:53 PM UTC, comment #1: 

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.

Nathaniel Smith <njs>
Group Member
Mon 02 May 2005 04:24:17 PM UTC, original submission:  

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...

Peter Gervai <grin>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

 

No changes have been made to this item

Back to the top

Powered by Savane 3.13-cf05.
Corresponding source code