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.
Received on 2014-01-03 06:36:09 CET