#7427 closed enhancement (wontfix)
Current revision parameter
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | general | Version: | |
Severity: | normal | Keywords: | |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
Developer can write fixed ticket numbers In SVN commit message, for example "Fixed #102, #344", and TracLinks manages links. And TrackLinks manages links like "source:/trunk/COPYING@200". If fixing a ticket affects some files, how developer can specify that files like this comment: "Fixed #102 source:/trunk/COPYING@CURRENT_REVISION,
He doesn't know revision number that generates after commit.
Attachments (0)
Change History (15)
comment:1 by , 16 years ago
follow-up: 3 comment:2 by , 16 years ago
follow-up: 4 comment:3 by , 16 years ago
Replying to alisol911@gmail.com:
No, it is not referring to any hook script. It is a convention in TracLinks that acts like # sign for ticket number, or r for revision number. When TracLinks engine parses a comment message, can replace CURRENT_REVISION parameter with revision number.
So I'm not sure to understand which value would take CURRENT_REVISION here? How would the CURRENT_REVISION be tied to a specific revision?
follow-up: 5 comment:4 by , 16 years ago
Replying to eblot: I can write
in any page in Trac like wiki, ticket description, and commit message in SVN. and Trac automatically creates a link to that file, so when I click the link, Trac shows the "COPYING file in trunk directory at revision 200". Before commit I don't know result revision number, but I write a message that "I changed a file in this revision", and I want Trac automatically shows the file at committed revision.
follow-up: 6 comment:5 by , 16 years ago
Replying to anonymous:
Before commit I don't know result revision number, but I write a message that "I changed a file in this revision", and I want Trac automatically shows the file at committed revision.
Ok, so I don't think it is possible at all: how would Trac know that a message you type at some time in the Wiki matches a specific version number in the repository?
Let's take an example:two users change the same file in a one minute lap time:
- user 1 commits a new revision o a the file into SVN, this creates a new SVN revision: rev1
- user 1 starts typing a message in a wiki page with
@CURRENT_REVISION
marker - user 2 commits a new revision of the same file, which creates a new SVN revision: rev2
- user 1 finally submits the wiki page
How Trac would know that by the time user 1 submits the wiki page, @CURRENT_REVISION
matches an old revision (rev1) whereas the "current revision" for the file is rev2?
follow-up: 7 comment:6 by , 16 years ago
Replying to eblot:
Ok, so I don't think it is possible at all: how would Trac know that a message you type at some time in the Wiki matches a specific version number in the repository?
Let's take an example:two users change the same file in a one minute lap time:
- user 1 commits a new revision o a the file into SVN, this creates a new SVN revision: rev1
- user 1 starts typing a message in a wiki page with
@CURRENT_REVISION
marker- user 2 commits a new revision of the same file, which creates a new SVN revision: rev2
- user 1 finally submits the wiki page
How Trac would know that by the time user 1 submits the wiki page,
@CURRENT_REVISION
matches an old revision (rev1) whereas the "current revision" for the file is rev2?
user 1 commits a new revision of a file into SVN, he writes a commit message that has @CURRENT_REVISION
marker. Trac knows message and revision number so can replace @CURRENT_REVISION
with revision number related to commit message.
follow-up: 8 comment:7 by , 16 years ago
Replying to alisol911@gmail.com:
user 1 commits a new revision of a file into SVN, he writes a commit message that has
@CURRENT_REVISION
marker. Trac knows message and revision number so can replace@CURRENT_REVISION
with revision number related to commit message.
This seems to be incoherent with your previous comments:
- Either it's a on-commit action and this is definitely tied to a commit hook script, see my initial comment, or
- It's in (quoting) "in any page in Trac like wiki, ticket description" and Trac has no way to tie the marker to a specific revision
Please elaborate your request, I'm getting lost with the somewhat contradictory previous comments.
follow-up: 9 comment:8 by , 16 years ago
Replying to eblot:
This seems to be incoherent with your previous comments:
- Either it's a on-commit action and this is definitely tied to a commit hook script, see my initial comment, or
- It's in (quoting) "in any page in Trac like wiki, ticket description" and Trac has no way to tie the marker to a specific revision
It is only a TracLinks manner example, and only ticket description is important. consider this example: Last revision in SVN is number 100. User 1 changes a file /trunk/foo.py and writes "Fixed #102 source:/trunk/foo.py@CURRENT_REVISION" in commit message. Result revision is 101. Trac replaces "CURRENT_REVISION" parameter with 101, so result string is "Fixed #102 source:/trunk/foo.py@101" and this syntax is a simple TrakLinks example:
Where to use TracLinks You can use TracLinks in: * Source code (Subversion) commit messages and any other text fields explicitly marked as supporting WikiFormatting. Some examples: * A specific file revision: source:/trunk/COPYING@200
follow-up: 10 comment:9 by , 16 years ago
Replying to alisol911@gmail.com:
Trac is a web application, with no background process. As such, Trac fetches information from SVN only when a user requests for a web page. This means there's no way Trac can "guess" the proper @CURRENT_REVISION value when it fetches information from SVN to serve a web request.
The only way to get the proper revision number is to push it to Trac using a commit hook script. This way, the expected information - the revision number - is known for sure w/o ambiguity.
So we're back to my original comment:
- the pre-commit hook script does not know the revision number as it does not exist yet,
- the post-commit hook script knows it, which means that @CURRENT_REVISION value could be replaced with the actual revision value at this very moment.
However, as the SVN log message is frozen by the time the post-commit hook script is called, although the ticket comment would contain the proper revision number, the SVN log message would still retain the @CURRENT_REVISION marker.
If it's ok for you to keep weird markers in SVN log messages such as the "@CURRENT_REVISION", then you want to edit the post-commit hook script to replace "@CURRENT_REVISION" with the revision number received as an argument of the post-commit hook script.
It seems weird to leave that "@CURRENT_REVISION" thing in SVN log message, IMHO. And there's no way to remove/replace it (but edit the log message) - which looks like more a ugly hack.
follow-up: 11 comment:10 by , 16 years ago
Replying to eblot:
Trac is a web application, with no background process. As such, Trac fetches information from SVN only when a user requests for a web page. This means there's no way Trac can "guess" the proper @CURRENT_REVISION value when it fetches information from SVN to serve a web request.
When Trac fethces information form SVN, revision number of any commit message is clear, for example in "Browse Source" section Trac shows SVN folders and files in tree view with columns like: Name, Size, Rev, Age, Last Change. Last Change is commit message, Rev is revision number, so Trac can replace CURRENT_REVISION parameter with revision number.
follow-up: 12 comment:11 by , 16 years ago
Replying to anonymous:
When Trac fethces information form SVN, revision number of any commit message is clear, for example in "Browse Source" section Trac shows SVN folders and files in tree view with columns like: Name, Size, Rev, Age, Last Change. Last Change is commit message, Rev is revision number, so Trac can replace CURRENT_REVISION parameter with revision number.
Trac sees the LAST revision number for a file, which may be different from the one that exists by the time you've committed the file, see my previous example: if another commit by the time Trac analyses the @CURRENT_REVISION marker, the revision number would be wrong.
If you simply want to point to the latest revision, you don't need @rev at all in TracLinks
comment:12 by , 16 years ago
Replying to eblot:
Trac sees the LAST revision number for a file, which may be different from the one that exists by the time you've committed the file.
Ok, LAST revision number is enough because Trac shows last commit message. In "Browse Source" Last Change is for Rev, so if you change "View revision", Last Change and Rev changes. consider this example:
http://trac.edgewall.org/browser HEAD revision
Name Size Rev Age Last Change trunk 7348 12 hours jruigrok: More Greek fixes.
http://trac.edgewall.org/browser?rev=7345
Name Size Rev Age Last Change trunk 7345 43 hours jruigrok: Force Babel 0.9.3 since it fixes some plurality issues.
follow-ups: 14 15 comment:13 by , 16 years ago
It is actually possible to change the log message in a post-commit hook, trac-hacks used to do that to prefix log messages with the hack name. This did cause issues where Trac would cache the commit log before the revprop change was committed, so a cron job was used to do a full resync once a day. I'm going to agree that this is more complicated than needed for the default system. The existing post-commit hook will put a link to the changeset before the log message when adding a comment, which is more than enough to get the data this user is looking for. +1 wontfix.
comment:14 by , 16 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Replying to nkantrowitz:
It is actually possible to change the log message in a post-commit hook, trac-hacks used to do that to prefix log messages with the hack name.
Yes you can, however you need to trigger a revprop change SVN action from within a post-commit hook.
I don't know if this is valid for SVN, but I think it's a bit hack-ish.
comment:15 by , 16 years ago
Replying to nkantrowitz:
It is actually possible to change the log message in a post-commit hook, trac-hacks used to do that to prefix log messages with the hack name.
BTW why is this not done in the pre-commit hook script?
svn:log
being a revision property, it's valid (from SVN persective) to change it on-the-fly within the pre-commit hook. This avoid any resync issue.
I'm not sure to understand the question, nor how it actually relates to Trac. Are you referring to the post commit hook script?
Anyway, the new revision is not know by the time the pre-commit hook script is called (as the revision number has not been yet generated) so you cannot know the revision number at this moment - a moment where it is still possible to change the log message on-the-fly.
When the post-commit hook script is called, the revision number is known, but you cannot change the log message at this time, it's too late.
In other words, you cannot change the SVN log message to include its self revision number.
However, you can update you trac post-commit hook script to that it parses the log message and recognizes a special tag such as "@CURRENT_REVISION" and replace it with the actual revision number before generating the Trac ticket comment. I don't think it's a great idea though as the SVN log message will keep the tag marker "@CURRENT_REVISION" anyway.