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.
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.
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.
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
$ 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) $
However if I compare the two with SVN:
$ svn diff https://svn.apache.org/repos/asf/subversion/branches/1.7.x/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.
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).
> 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
Your suggested solution would complicate keywords and make them harder to use
for their intended purpose. If a user 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.
So in my opinion I don't think this is a good suggested feature.
Received on 2014-01-03 19:02:44 CET