On Fri, Jan 3, 2014 at 12:35 AM, Ben Reser <ben_at_reser.org> wrote:
> 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.
>
Can you expand on this - I am missing where the preceding differences would
be an issue. From what I can see, if there is a delta, it is either the
result of direct modification or a merge - if the former, that would be the
rev expanding the keyword, if the later, the library/client/server would
need to trace through the most recent svn:mergeinfo in an analogous method
to "log -g" until it finds a delta without mergeinfo - which should be a a
direct modification and the delta indicated.
One corner case may be "undoing" changes with "svn merge -c -X
filewithkeyword.txt ; svn ci" but this should use the original keyword
expansion prior to X - assuming the keyword would be using merge history.
>
> 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.
>
I believe I understand the this case you speak of, for my own benefit of
visualizing the case better, if we have the change graph:
1 - * /trunk - create project
|\
| \
| \
2 - | * /branches/1.7.x - create branch
3 - | * /branches/1.7.x - some 1.7 specific changes
|\ |
4 - | * | /branches/1.8.x - create branch
5 - | * | /branches/1.8.x - some 1.8 specific changes
6 - * | | /trunk - some trunk generic changes
7 - | | * /branches/1.7.x - some more 1.7 specific changes
8 - | * | /branches/1.8.x - some more 1.8 specific changes
|\| |
9 - | * | /branches/1.8.x - merge from trunk
|\| |
| \ |
| |\|
10 - | | * /branches/1.7.x - merge from trunk
! ! !
: : :
In this case r10 and r9's corresponding merge aware keywords would expand
to r6 even though there were chronological changes r7 & r8 respective of
each branch for those files that happened after r6 on each of those
branches. In this case it is possible to have very different contents for
each file of each branch.
However, in the simple case of merging back changes:
1 - * /trunk - create project
|\
2 - | * /branches/1.8.x - some change
3 - * | /trunk - some more changes
4 - * | /trunk - even more changes
5 - | * /branches/1.8.x - some more changes
6 - | * /branches/1.8.x - even more changes
7 - * | /trunk - one more change
|\|
8 - | * /branches/1.8.x - merge missing changes from trunk
|/|
9 - * | /trunk - merge missing changes from branch 1.8.x
! !
: :
After r9, in theory, if there was an export done on the trunk and the
branch, they should be identical, but the keywords (without the concept of
merge aware keywords) would show a difference on every file that the
keywords are used, since the branch would expand to show r9 and the trunk
would expand to show r8. In the case of a merge aware keyword, the keyword
would expand to the last non-merged delta - so a file in r5 changed would
show r5 on the trunk after the merge of r9, and a file changed in r4 would
show r4 in the branch after the merge of r8 - even though the file may have
changed in r6, but chronologically the last change was the merge of r6.
>
> 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.
>
So the example above with merging changes back down to the trunk would be
an example, and our need would be for during the release process for
validating all changes are completely synchronized and that there are no
missing changes between branches, but aside from our need, it just doesn't
seem right that there would show differences between the exported branches.
I'm not suggesting the existing behavior be changed, just give the option
to the user to configure the expansion.
Thanks much,
-Jim
Received on 2014-01-03 18:01:24 CET