You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Eric Gillespie <ep...@pretzelnet.org> on 2007/08/02 23:35:35 UTC
URL-URL merging (e.g. tags) and notification
A common use case is to merge the changes between two tags:
0 branch-from-tag1% svn merge $r/tag1 $r/tag2
--- Merging r8:
U file1
I have included a dump of this test repository at the end of this
message. tag1 is copied from trunk@1 in r2, tag2 is copied from
trunk@4 in r5, and branch-from-tag1 is copied from tag1@4 (same
as tag1@2). At the time I run this command, HEAD is 8 and the wc
is fully updated to 8.
The merge is correct; commit and diff $r/tag2 $r/branch-from-tag1
to prove that. But I think the reporting is off. Conceptually,
this is the same as 'svn merge -r2:4 $r/trunk' and r8 isn't
involved at all. I know and you know that we referred to tag1
and tag2 as of r8, but even though I understand that, I still
find this output highly misleading. This I expect:
0 branch-from-trunk% svn merge -c 8 $r/trunk
--- Merging r8:
U file1
"Merging r8" is not at all what I expect from the earlier
command, though. We could print something like
--- Merging tag1@r8 tag2@r8
but I'm not sure that's useful either. Maybe we should just not
print a --- Merging line at all.
I made a small change libsvn_client/merge.c to play with:
Index: merge.c
===================================================================
--- merge.c (revision 25935)
+++ merge.c (working copy)
@@ -1705,7 +1705,13 @@
}
if (notify_b->wrapped_func)
- (*notify_b->wrapped_func)(notify_b->wrapped_baton, notify, pool);
+ {
+ /* If merging two different URLs (e.g. svn merge $r/tag1
+ $r/tag2), don't notify callers of merge_begin. */
+ if (!(notify->action == svn_wc_notify_merge_begin
+ && !notify_b->same_urls))
+ (*notify_b->wrapped_func)(notify_b->wrapped_baton, notify, pool);
+ }
}
#if 0
and it works:
0 branch-from-tag1% svn merge $r/tag1 $r/tag2
U file1
But, I'm not sure this is the right answer. Thoughts?
SVN-fs-dump-format-version: 2
UUID: 132ea034-4148-11dc-af71-9567b1d477e3
Revision-number: 0
Prop-content-length: 56
Content-length: 56
K 8
svn:date
V 27
2007-08-02T22:31:12.960524Z
PROPS-END
Revision-number: 1
Prop-content-length: 97
Content-length: 97
K 7
svn:log
V 0
K 10
svn:author
V 3
epg
K 8
svn:date
V 27
2007-08-02T22:31:26.094117Z
PROPS-END
Node-path: trunk
Node-kind: dir
Node-action: add
Prop-content-length: 10
Content-length: 10
PROPS-END
Node-path: trunk/file1
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 2
Text-content-md5: b026324c6904b2a9cb4b88d6d61c81d1
Content-length: 12
PROPS-END
1
Revision-number: 2
Prop-content-length: 97
Content-length: 97
K 7
svn:log
V 0
K 10
svn:author
V 3
epg
K 8
svn:date
V 27
2007-08-02T22:31:30.280410Z
PROPS-END
Node-path: tag1
Node-kind: dir
Node-action: add
Node-copyfrom-rev: 1
Node-copyfrom-path: trunk
Revision-number: 3
Prop-content-length: 97
Content-length: 97
K 7
svn:log
V 0
K 10
svn:author
V 3
epg
K 8
svn:date
V 27
2007-08-02T22:31:34.215487Z
PROPS-END
Node-path: trunk/file1
Node-kind: file
Node-action: change
Text-content-length: 4
Text-content-md5: 6ddb4095eb719e2a9f0a3f95677d24e0
Content-length: 4
1
2
Revision-number: 4
Prop-content-length: 97
Content-length: 97
K 7
svn:log
V 0
K 10
svn:author
V 3
epg
K 8
svn:date
V 27
2007-08-02T22:31:50.809826Z
PROPS-END
Node-path: trunk/file1
Node-kind: file
Node-action: change
Text-content-length: 6
Text-content-md5: c0710d6b4f15dfa88f600b0e6b624077
Content-length: 6
1
2
3
Revision-number: 5
Prop-content-length: 97
Content-length: 97
K 7
svn:log
V 0
K 10
svn:author
V 3
epg
K 8
svn:date
V 27
2007-08-02T22:34:35.110689Z
PROPS-END
Node-path: tag2
Node-kind: dir
Node-action: add
Node-copyfrom-rev: 4
Node-copyfrom-path: trunk
Revision-number: 6
Prop-content-length: 97
Content-length: 97
K 7
svn:log
V 0
K 10
svn:author
V 3
epg
K 8
svn:date
V 27
2007-08-02T22:34:44.833200Z
PROPS-END
Node-path: branch-from-tag1
Node-kind: dir
Node-action: add
Node-copyfrom-rev: 4
Node-copyfrom-path: tag1
Revision-number: 7
Prop-content-length: 97
Content-length: 97
K 7
svn:log
V 0
K 10
svn:author
V 3
epg
K 8
svn:date
V 27
2007-08-02T22:34:57.828471Z
PROPS-END
Node-path: branch-from-trunk
Node-kind: dir
Node-action: add
Node-copyfrom-rev: 4
Node-copyfrom-path: trunk
Revision-number: 8
Prop-content-length: 97
Content-length: 97
K 7
svn:log
V 0
K 10
svn:author
V 3
epg
K 8
svn:date
V 27
2007-08-02T22:35:16.459218Z
PROPS-END
Node-path: trunk/file1
Node-kind: file
Node-action: change
Text-content-length: 8
Text-content-md5: 302c28003d487124d97c242de94da856
Content-length: 8
1
2
3
4
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: URL-URL merging (e.g. tags) and notification
Posted by Mark Phippard <ma...@gmail.com>.
On 8/2/07, Eric Gillespie <ep...@pretzelnet.org> wrote:
> A common use case is to merge the changes between two tags:
>
> 0 branch-from-tag1% svn merge $r/tag1 $r/tag2
> --- Merging r8:
> U file1
>
> I have included a dump of this test repository at the end of this
> message. tag1 is copied from trunk@1 in r2, tag2 is copied from
> trunk@4 in r5, and branch-from-tag1 is copied from tag1@4 (same
> as tag1@2). At the time I run this command, HEAD is 8 and the wc
> is fully updated to 8.
>
> The merge is correct; commit and diff $r/tag2 $r/branch-from-tag1
> to prove that. But I think the reporting is off. Conceptually,
> this is the same as 'svn merge -r2:4 $r/trunk' and r8 isn't
> involved at all. I know and you know that we referred to tag1
> and tag2 as of r8, but even though I understand that, I still
> find this output highly misleading. This I expect:
>
> 0 branch-from-trunk% svn merge -c 8 $r/trunk
> --- Merging r8:
> U file1
>
> "Merging r8" is not at all what I expect from the earlier
> command, though. We could print something like
>
> --- Merging tag1@r8 tag2@r8
>
> but I'm not sure that's useful either. Maybe we should just not
> print a --- Merging line at all.
>
> I made a small change libsvn_client/merge.c to play with:
I had to read this a few times to understand it, but once I did I have
to say I agree with you. The current notification is just not right
or of any value. If someone can come up with a reasonable idea for a
notification that adds some value that would be good, but otherwise
I'd say just no notification.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org