> On Jan 3, 2014, at 12:58 PM, Ben Reser <ben_at_reser.org> wrote:
>
>> On 1/3/14, 8:59 AM, James Hanley wrote:
>> 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.
>
> At least in my opinion the entire purpose of the keywords feature is to allow
> people to embed data into exports and checkouts that uniquely identify the
> files so that the exact version being used can be found in version control.
This is probably the best argument against the idea - the small caveat to our flow (which I didn't show in my example graph) is that the /trunk is off limits for direct deltas on our program - meaning it is a merge only destination - even for the most minor of edits - so large sweeps of changes in a branch are bundled under one merge change, unless each delta from the bench is merged and checked in independently.
>
> Your feature subverts that entirely. You seem to understand that with your
> response to my example.
>
>> 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.
>
> I'm going to ignore the fact that in your example they might not be identical
> since you made changes in r5 and r6 to /branches/1.8.x that weren't coming from
> trunk, since I don't think it's important to understanding what you want.
> Let's just pretend those were merges from trunk.
I believe you are correct in saying, it shouldn't mater, but those were changes in that branch branch, independent of the trunk and later merged into the trunk in rev9 via the hidden auto-reintegrate of svn1.8
>
> So what you're trying to solve is that a diff of /branches/1.8.x and /trunk
> show spurious changes? Why don't you just ask Subversion to compare them
> before doing the export. The diffs we produce ignore the keywords.
Unfortunately, that's not an option, but I understand it would easily overcome the false positive check for spurious changes.
>
> For example consider the README file at the root of the Subversion source.
>
> As you can see with a diff command between 1.7.x and trunk I get a delta on the
> keyword:
> [[[
> $ diff -u svn-1.7.x/README svn-trunk/README
> --- svn-1.7.x/README 2013-07-16 09:54:11.000000000 -0700
> +++ svn-trunk/README 2013-11-01 13:46:21.000000000 -0700
> @@ -2,7 +2,7 @@
> Subversion, a version control system.
> =====================================
>
> -$LastChangedDate: 2011-06-30 10:54:40 -0700 (Thu, 30 Jun 2011) $
> +$LastChangedDate: 2012-02-10 06:58:53 -0800 (Fri, 10 Feb 2012) $
>
> Contents:
>
> ]]]
>
> However if I compare the two with SVN:
> [[[
> $ svn diff https://svn.apache.org/repos/asf/subversion/branches/1.7.x/README
> https://svn.apache.org/repos/asf/subversion/trunk/README
>
> ]]]
>
> I get no output because there are no differences.
>
> If that doesn't work for you then you can export with --ignore-keywords. And
> do the diff the same way you are now.
This might be the best workaround for us.
>
> Keep in mind you can use -r options in order to make sure you're comparing
> exactly the same versions as your real export is going to use when you do it.
>
> You could also use the mergeinfo command with --show-revs to list out what is
> eligible to merge. I.E.
>
> [[[
> $ svn mergeinfo --show-revs=eligible ^/subversion/trunk ^/subversion/branches/1.8.x
> ]]]
>
> Which is going to list of all of the changes that have not been merged
> completely to the branch. In your case if all of the changes made to trunk
> since 1.8.x was branched, then you should get no output.
>
> In 1.9.0 mergeinfo should have a --log option which will give you output like
> log would instead of just a list of revision numbers (trunk does but I can't
> promise that it won't be removed or changed before 1.9.0).
This is intriguing but we cannot use 1.9.0 until officially released.
>
>> 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.
>
> I don't think your suggested solution to your issue is better than the existing
> solutions.
>
> Your suggested solution would complicate keywords and make them harder to use
> for their intended purpose. If a user
Agreed that it complicates, as the intension was to not modify and maintain existing behavior while providing a way to augment the expansion, but the concept of keywords pre-dates merge history meta data, so the original intent for keywords had no visibility to such use cases or information as it didn't exist.
> turned your proposed feature on as in my
> example then the keywords would not be functional for determining the exact
> code in source control that the user was using. Using this setting would be
> error prone because a user would have to know their branching model when they
> set it which may change in the future.
Right now it tells you precisely the change but not accurately if it was the result of a merge - precisely because you know what delta the merged was checked into, but not accurately as you know have to run through log -g to trace the origin of that merge - which is all thus is trying to do for the user, if they choose to use it for that file.
>
> So in my opinion I don't think this is a good suggested feature.
Fair enough, and one of the workarounds you previously mentioned may be useful, but in my opinion there is still gap between keywords and merge history even if this specific feature proposal is not a desired solution to close that gap.
Where do we go from here?
Jim
Received on 2014-01-04 08:48:20 CET