You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "C. Michael Pilato" <cm...@collab.net> on 2010/05/10 16:20:03 UTC

Re: svn commit: r942802 - in /subversion/trunk/subversion: libsvn_client/commit_util.c tests/cmdline/merge_tests.py

philip@apache.org wrote:
> Author: philip
> Date: Mon May 10 16:00:53 2010
> New Revision: 942802
> 
> URL: http://svn.apache.org/viewvc?rev=942802&view=rev
> Log:
> More svn_wc_entry_t removal.  This changes the commit notification in
> some cases, but the new notification seems more consistent with the
> changes made in the repository.

Explain?  What changed?  Why?

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand


Re: svn commit: r942802 - in /subversion/trunk/subversion: libsvn_client/commit_util.c tests/cmdline/merge_tests.py

Posted by Philip Martin <ph...@wandisco.com>.
Greg Stein <gs...@gmail.com> writes:

> On Mon, May 10, 2010 at 13:34, C. Michael Pilato <cm...@collab.net> wrote:
>>...
>> I asked about this because commit notification and action are pretty
>> intimately entangled:  if the notification is different, we almost certainly
>> changed what got sent thru the commit editor, too.  That may be fine in this
>
> Agreed!
>
> I also worry when I see the commit output changing.

Me too, but in this case the old notification looked suspect.  Commit
used to send "extra" notifications for children of a directory added
by merge, but in this case it was only sending extra notification for
the directory child, not the file children.

-- 
Philip

Re: svn commit: r942802 - in /subversion/trunk/subversion: libsvn_client/commit_util.c tests/cmdline/merge_tests.py

Posted by Greg Stein <gs...@gmail.com>.
On Mon, May 10, 2010 at 13:34, C. Michael Pilato <cm...@collab.net> wrote:
>...
> I asked about this because commit notification and action are pretty
> intimately entangled:  if the notification is different, we almost certainly
> changed what got sent thru the commit editor, too.  That may be fine in this

Agreed!

I also worry when I see the commit output changing.

> case, but I just want to ensure that you've done the necessary thoughtwork
> around cases that may not be represented in our test suite.  (No specific
> tricky cases come to mind right now.)
>
> Does this mean that we no longer have the weirdness that 'svn cp REPOS WC'
> would create a tree like this:
>
>    WC/target             # scheduled as a real copy target
>    WC/target/subthing    # annotated as 'copied', but not a copy target
>    WC/target/subthing2   # annotated as 'copied', but not a copy target
>    ...
>
> but an 'svn merge' that adds a tree would do this:
>
>    WC/target             # scheduled as a real copy target
>    WC/target/subthing    # scheduled as a real copy target
>    WC/target/subthing2   # scheduled as a real copy target
>    ...

The merge tree output might not happen as much any more. See
notes/api-errata/wc003.txt

Cheers,
-g

Re: svn commit: r942802 - in /subversion/trunk/subversion: libsvn_client/commit_util.c tests/cmdline/merge_tests.py

Posted by Philip Martin <ph...@wandisco.com>.
"C. Michael Pilato" <cm...@collab.net> writes:

> Does this mean that we no longer have the weirdness that 'svn cp REPOS WC'
> would create a tree like this:
>
>     WC/target             # scheduled as a real copy target
>     WC/target/subthing    # annotated as 'copied', but not a copy target
>     WC/target/subthing2   # annotated as 'copied', but not a copy target
>     ...
>
> but an 'svn merge' that adds a tree would do this:
>
>     WC/target             # scheduled as a real copy target
>     WC/target/subthing    # scheduled as a real copy target
>     WC/target/subthing2   # scheduled as a real copy target
>     ...
>
> ?

That has changed, but I think it was before r942802.

-- 
Philip

Re: svn commit: r942802 - in /subversion/trunk/subversion: libsvn_client/commit_util.c tests/cmdline/merge_tests.py

Posted by "C. Michael Pilato" <cm...@collab.net>.
Philip Martin wrote:
> $ svn diff -cr942802 ../src/subversion/tests/cmdline/merge_tests.py
> Index: ../src/subversion/tests/cmdline/merge_tests.py
> ===================================================================
> --- ../src/subversion/tests/cmdline/merge_tests.py      (revision 942801)
> +++ ../src/subversion/tests/cmdline/merge_tests.py      (revision 942802)
> @@ -3009,7 +3009,6 @@
>    expected_output = svntest.wc.State(wc_dir, {
>      'A/C'                    : Item(verb='Sending'),
>      'A/C/foo'                : Item(verb='Replacing'),
> -    'A/C/foo/bar'            : Item(verb='Adding'),
>      })
>  
>    expected_status = svntest.actions.get_virginal_state(wc_dir, 1)
> @@ -3029,6 +3028,16 @@
>                                          expected_status,
>                                          None, wc_dir)
>  
> 
> It's a merge that replaces a directory.  The commit used to generate
> an 'Adding' notification for one of the chidren. The change in the
> repository looks like:
> 
> $ svn log -vqrhead file://`pwd`/svn-test-work/repositories/merge_tests-34/
> ------------------------------------------------------------------------
> r6 | jrandom | 2010-05-10 17:39:24 +0100 (Mon, 10 May 2010)
> Changed paths:
>    M /A/C
>    R /A/C/foo (from /A/B/F/foo:5)
> 
> A/C/foo/bar is not explicitly changed and that was also the case
> before r942802.

I asked about this because commit notification and action are pretty
intimately entangled:  if the notification is different, we almost certainly
changed what got sent thru the commit editor, too.  That may be fine in this
case, but I just want to ensure that you've done the necessary thoughtwork
around cases that may not be represented in our test suite.  (No specific
tricky cases come to mind right now.)

Does this mean that we no longer have the weirdness that 'svn cp REPOS WC'
would create a tree like this:

    WC/target             # scheduled as a real copy target
    WC/target/subthing    # annotated as 'copied', but not a copy target
    WC/target/subthing2   # annotated as 'copied', but not a copy target
    ...

but an 'svn merge' that adds a tree would do this:

    WC/target             # scheduled as a real copy target
    WC/target/subthing    # scheduled as a real copy target
    WC/target/subthing2   # scheduled as a real copy target
    ...

?

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand


Re: svn commit: r942802 - in /subversion/trunk/subversion: libsvn_client/commit_util.c tests/cmdline/merge_tests.py

Posted by Philip Martin <ph...@wandisco.com>.
"C. Michael Pilato" <cm...@collab.net> writes:

> philip@apache.org wrote:
>> Author: philip
>> Date: Mon May 10 16:00:53 2010
>> New Revision: 942802
>> 
>> URL: http://svn.apache.org/viewvc?rev=942802&view=rev
>> Log:
>> More svn_wc_entry_t removal.  This changes the commit notification in
>> some cases, but the new notification seems more consistent with the
>> changes made in the repository.
>
> Explain?  What changed?  Why?

$ svn diff -cr942802 ../src/subversion/tests/cmdline/merge_tests.py
Index: ../src/subversion/tests/cmdline/merge_tests.py
===================================================================
--- ../src/subversion/tests/cmdline/merge_tests.py      (revision 942801)
+++ ../src/subversion/tests/cmdline/merge_tests.py      (revision 942802)
@@ -3009,7 +3009,6 @@
   expected_output = svntest.wc.State(wc_dir, {
     'A/C'                    : Item(verb='Sending'),
     'A/C/foo'                : Item(verb='Replacing'),
-    'A/C/foo/bar'            : Item(verb='Adding'),
     })
 
   expected_status = svntest.actions.get_virginal_state(wc_dir, 1)
@@ -3029,6 +3028,16 @@
                                         expected_status,
                                         None, wc_dir)
 

It's a merge that replaces a directory.  The commit used to generate
an 'Adding' notification for one of the chidren. The change in the
repository looks like:

$ svn log -vqrhead file://`pwd`/svn-test-work/repositories/merge_tests-34/
------------------------------------------------------------------------
r6 | jrandom | 2010-05-10 17:39:24 +0100 (Mon, 10 May 2010)
Changed paths:
   M /A/C
   R /A/C/foo (from /A/B/F/foo:5)

A/C/foo/bar is not explicitly changed and that was also the case
before r942802.

-- 
Philip