You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Bert Huijben <rh...@sharpsvn.net> on 2009/10/17 15:55:32 UTC
RE: svn commit: r40087 - trunk/subversion/libsvn_wc
> -----Original Message-----
> From: Stefan Sperling [mailto:stsp@elego.de]
> Sent: zaterdag 17 oktober 2009 0:25
> To: svn@subversion.tigris.org
> Subject: svn commit: r40087 - trunk/subversion/libsvn_wc
>
> Author: stsp
> Date: Fri Oct 16 15:25:22 2009
> New Revision: 40087
>
> Log:
> * subversion/libsvn_wc/diff.c
> (file_diff): Stop using svn_wc_entry_t and get desired information
> from the WC-NG APIs instead. This function no longer takes an ENTRY
> parameter. The logic deciding whether to show a delete, add, or
> modification diff needed some reshuffling because it was heavily
> tied
> to the obsolete concept of "schedule". Also narrow the scope of a
> couple of variables while here.
> (directory_elements_diff, report_wc_file_as_added): Adjust callers.
FYI. This commit causes test failures in
FAIL: merge_tests.py 18: diff after merge that creates a new file
FAIL: special_tests.py 10: diff a symlink to a directory
Bert
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2408538
RE: svn commit: r40087 - trunk/subversion/libsvn_wc
Posted by Bert Huijben <rh...@sharpsvn.net>.
> -----Original Message-----
> From: Stefan Sperling [mailto:stsp@elego.de]
> Sent: zaterdag 17 oktober 2009 19:40
> To: Bert Huijben
> Cc: dev@subversion.tigris.org
> Subject: Re: svn commit: r40087 - trunk/subversion/libsvn_wc
>
> On Sat, Oct 17, 2009 at 05:55:32PM +0200, Bert Huijben wrote:
> > > Author: stsp
> > > Date: Fri Oct 16 15:25:22 2009
> > > New Revision: 40087
> > >
> > > Log:
> > > * subversion/libsvn_wc/diff.c
> > > (file_diff): Stop using svn_wc_entry_t and get desired
> information
> > > from the WC-NG APIs instead. This function no longer takes an
> ENTRY
> > > parameter. The logic deciding whether to show a delete, add, or
> > > modification diff needed some reshuffling because it was heavily
> > > tied
> > > to the obsolete concept of "schedule". Also narrow the scope of
> a
> > > couple of variables while here.
> > > (directory_elements_diff, report_wc_file_as_added): Adjust
> callers.
> >
> > FYI. This commit causes test failures in
> >
> > FAIL: merge_tests.py 18: diff after merge that creates a new file
>
> This test expects the revision for added files reported in diff header
> to be the revision of the file's parent dir (in this case, revision 2):
>
> Index: svn-test-work/working_copies/merge_tests-18/branch/newfile
> ===================================================================
> --- svn-test-work/working_copies/merge_tests-18/branch/newfile
> (revision 0)
> +++ svn-test-work/working_copies/merge_tests-18/branch/newfile
> (revision 2)
>
> SVN info also shows this revision:
> $ svn info svn-test-work/working_copies/merge_tests-18/branch/newfile
> Name: newfile
> [...]
> Revision: 2
> [...]
>
> But since my commit the diff header has been printing 'working copy'
> instead of 'revision 2'.
>
> To fix this test, I need to know what the paradigm for WC-NG is.
> Should the parent's rev still be displayed, or do we simply adjust
> the expected test output to the current behaviour?
>
> The backwards compat code in entries.c makes sure that added nodes
> inherit
> their parent's revision. See take_from_entry() in entries.c.
> That's why these tests weren't failing before.
>
> svn_wc__db_read_info reports INVALID_REVNUM for added nodes, and
> the scan_addition function has no "parent_revision" output parameter,
> so it looks like manual scanning of the parent is in order which would
> be quite ugly. I don't really see the point of keeping this behaviour
> if WC-NG does not default to it. As far as I can see it's not even
> documented which revisions 'svn diff' should print in diff headers and
> why.
>
> > FAIL: special_tests.py 10: diff a symlink to a directory
>
> This is failing for similar reasons (expects 'revision 0' in diff
> header, gets 'working copy' instead.)
Without looking into the details (but before sending the original mail), I
guessed that the new output is better than the old version. There are no
valid paths in revision 0 and an addition/replacement referring to a parent
revision is also something we try to avoid now.
+1 on changing the expected test output.
Bert
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2408649
Re: svn commit: r40087 - trunk/subversion/libsvn_wc
Posted by Stefan Sperling <st...@elego.de>.
On Sat, Oct 17, 2009 at 05:55:32PM +0200, Bert Huijben wrote:
> > Author: stsp
> > Date: Fri Oct 16 15:25:22 2009
> > New Revision: 40087
> >
> > Log:
> > * subversion/libsvn_wc/diff.c
> > (file_diff): Stop using svn_wc_entry_t and get desired information
> > from the WC-NG APIs instead. This function no longer takes an ENTRY
> > parameter. The logic deciding whether to show a delete, add, or
> > modification diff needed some reshuffling because it was heavily
> > tied
> > to the obsolete concept of "schedule". Also narrow the scope of a
> > couple of variables while here.
> > (directory_elements_diff, report_wc_file_as_added): Adjust callers.
>
> FYI. This commit causes test failures in
>
> FAIL: merge_tests.py 18: diff after merge that creates a new file
This test expects the revision for added files reported in diff header
to be the revision of the file's parent dir (in this case, revision 2):
Index: svn-test-work/working_copies/merge_tests-18/branch/newfile
===================================================================
--- svn-test-work/working_copies/merge_tests-18/branch/newfile (revision 0)
+++ svn-test-work/working_copies/merge_tests-18/branch/newfile (revision 2)
SVN info also shows this revision:
$ svn info svn-test-work/working_copies/merge_tests-18/branch/newfile
Name: newfile
[...]
Revision: 2
[...]
But since my commit the diff header has been printing 'working copy'
instead of 'revision 2'.
To fix this test, I need to know what the paradigm for WC-NG is.
Should the parent's rev still be displayed, or do we simply adjust
the expected test output to the current behaviour?
The backwards compat code in entries.c makes sure that added nodes inherit
their parent's revision. See take_from_entry() in entries.c.
That's why these tests weren't failing before.
svn_wc__db_read_info reports INVALID_REVNUM for added nodes, and
the scan_addition function has no "parent_revision" output parameter,
so it looks like manual scanning of the parent is in order which would
be quite ugly. I don't really see the point of keeping this behaviour
if WC-NG does not default to it. As far as I can see it's not even
documented which revisions 'svn diff' should print in diff headers and why.
> FAIL: special_tests.py 10: diff a symlink to a directory
This is failing for similar reasons (expects 'revision 0' in diff
header, gets 'working copy' instead.)
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2408560