On 1/2/14, 7:16 PM, James Hanley wrote: > I've used the Rev keyword in some of our code, and we noticed that there may > be > a use case gap for the Rev/Revision and possibly Id keyword. > > As expected the keyword gets updated with any checkin, but there may be a need > to have a merge-history aware version these keywords. Meaning that the Rev > shown from a merge isn't the actual checkin of the merge, but the change > origin > of the merge. > > So the use case would be branching a project P from the trunk to do some work, > them merging those changes back. In its current form, the rev takes the > revision of the merged checkin rather then the origin of the merged change. > > We see a need for this capability of having a merge-history aware keyword, and > one way to accomplish this without adding yet another keyword would be to have > the existing keywords support some kind of argument like options.
The ONLY way to uniquely identify a point in history for a path is with the revision for that path (even a timestamp isn't unique since we allow dates that aren't sequential in the repository, yes this breaks using dates with -r). You can't identify the point in history a file is from on a path from the source of the merge because that doesn't account for any preceding differences. Consider a change to /trunk that gets merged to /branches/1.7.x and /branches/1.8.x. If you set the keywords based on the trunk revision that was merged then the changed files in 1.7.x and 1.8.x would show the same keyword info, even though they may be drastically different. You say that "you see a need for this capability" and then immediately launch into ideas for how to implement it. I'd focus on explaining why you see the need for the capability before we get to any discussion about how to implement it.