You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by hw...@apache.org on 2011/05/03 21:04:24 UTC
svn commit: r1099193 - in /subversion/trunk/subversion:
libsvn_client/deprecated.c libsvn_wc/info.c tests/cmdline/info_tests.py
Author: hwright
Date: Tue May 3 19:04:24 2011
New Revision: 1099193
URL: http://svn.apache.org/viewvc?rev=1099193&view=rev
Log:
For info, don't fake a completely bogus revision for added nodes, just
report an invalid revision.
In updating the tests, I noticed we report "Resource is not under version
control" in the XML for nodes with invalid revnums. While this isn't
strictly true for added nodes, I'll leave that fix for future change.
* subversion/tests/cmdline/info_tests.py
(info_on_added, info_on_mkdir): Update expectations.
* subversion/libsvn_wc/info.c
(build_info_for_entry): Remove special case setting the revision to 0 if
it isn't valid.
* subversion/libsvn_client/deprecated.c
(info_from_info2): Maintain the old behavior for the deprecated struct.
Modified:
subversion/trunk/subversion/libsvn_client/deprecated.c
subversion/trunk/subversion/libsvn_wc/info.c
subversion/trunk/subversion/tests/cmdline/info_tests.py
Modified: subversion/trunk/subversion/libsvn_client/deprecated.c
URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_client/deprecated.c?rev=1099193&r1=1099192&r2=1099193&view=diff
==============================================================================
--- subversion/trunk/subversion/libsvn_client/deprecated.c (original)
+++ subversion/trunk/subversion/libsvn_client/deprecated.c Tue May 3 19:04:24 2011
@@ -2009,7 +2009,12 @@ info_from_info2(const svn_info2_t *info2
svn_info_t *info = apr_pcalloc(pool, sizeof(*info));
info->URL = info2->URL;
- info->rev = info2->rev;
+ /* Goofy backward compat handling for added nodes. */
+ if (SVN_IS_VALID_REVNUM(info2->rev))
+ info->rev = info2->rev;
+ else
+ info->rev = 0;
+
info->kind = info2->kind;
info->repos_root_URL = info2->repos_root_URL;
info->repos_UUID = info2->repos_UUID;
Modified: subversion/trunk/subversion/libsvn_wc/info.c
URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_wc/info.c?rev=1099193&r1=1099192&r2=1099193&view=diff
==============================================================================
--- subversion/trunk/subversion/libsvn_wc/info.c (original)
+++ subversion/trunk/subversion/libsvn_wc/info.c Tue May 3 19:04:24 2011
@@ -111,20 +111,11 @@ build_info_for_entry(svn_info2_t **info,
else
tmpinfo->rev = rev;
- /* ### FIXME: For now, we'll tweak an SVN_INVALID_REVNUM and make it
- ### 0. In WC-1, files scheduled for addition were assigned
- ### revision=0. This is wrong, and we're trying to remedy that,
- ### but for the sake of test suite and code sanity now in WC-NG,
- ### we'll just maintain the old behavior.
- ###
- ### We should also just be fetching the true BASE revision
+ /* ### We should also just be fetching the true BASE revision
### above, which means copied items would also not have a
### revision to display. But WC-1 wants to show the revision of
### copy targets as the copyfrom-rev. *sigh*
*/
- if (! SVN_IS_VALID_REVNUM(tmpinfo->rev))
- tmpinfo->rev = 0;
-
tmpinfo->wc_info->copyfrom_rev = SVN_INVALID_REVNUM;
if (is_copy)
Modified: subversion/trunk/subversion/tests/cmdline/info_tests.py
URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/tests/cmdline/info_tests.py?rev=1099193&r1=1099192&r2=1099193&view=diff
==============================================================================
--- subversion/trunk/subversion/tests/cmdline/info_tests.py (original)
+++ subversion/trunk/subversion/tests/cmdline/info_tests.py Tue May 3 19:04:24 2011
@@ -227,7 +227,6 @@ def info_on_added_file(sbox):
'Name' : 'new_file',
'URL' : '.*/new_file',
'Repository Root' : '.*',
- 'Revision' : '0',
'Node Kind' : 'file',
'Schedule' : 'add',
'Repository UUID' : uuid_regex,
@@ -244,7 +243,7 @@ def info_on_added_file(sbox):
verify_xml_elements(output,
[('entry', {'kind' : 'file',
'path' : new_file,
- 'revision' : '0'}),
+ 'revision' : 'Resource is not under version control.'}),
('url', {}, '.*/new_file'),
('root', {}, '.*'),
('uuid', {}, uuid_regex),
@@ -266,7 +265,6 @@ def info_on_mkdir(sbox):
expected = {'Path' : re.escape(new_dir),
'URL' : '.*/new_dir',
'Repository Root' : '.*',
- 'Revision' : '0',
'Node Kind' : 'directory',
'Schedule' : 'add',
'Repository UUID' : uuid_regex,
@@ -282,7 +280,7 @@ def info_on_mkdir(sbox):
verify_xml_elements(output,
[('entry', {'kind' : 'dir',
'path' : new_dir,
- 'revision' : '0'}),
+ 'revision' : 'Resource is not under version control.'}),
('url', {}, '.*/new_dir'),
('root', {}, '.*'),
('uuid', {}, uuid_regex),
Re: svn commit: r1099193 - in /subversion/trunk/subversion:
libsvn_client/deprecated.c libsvn_wc/info.c tests/cmdline/info_tests.py
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Tue, May 3, 2011 at 3:23 PM, Greg Stein <gs...@gmail.com> wrote:
> On Tue, May 3, 2011 at 15:35, Hyrum K Wright <hy...@hyrumwright.org> wrote:
>> On Tue, May 3, 2011 at 2:24 PM, Greg Stein <gs...@gmail.com> wrote:
>>> On Tue, May 3, 2011 at 15:04, <hw...@apache.org> wrote:
>>>> Author: hwright
>>>> Date: Tue May 3 19:04:24 2011
>>>> New Revision: 1099193
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=1099193&view=rev
>>>> Log:
>>>> For info, don't fake a completely bogus revision for added nodes, just
>>>> report an invalid revision.
>>>>
>>>> In updating the tests, I noticed we report "Resource is not under version
>>>> control" in the XML for nodes with invalid revnums. While this isn't
>>>> strictly true for added nodes, I'll leave that fix for future change.
>>>
>>> Eh? Shouldn't those tests be marked with XFail, rather than BAD OUTPUT?
>>
>> I'm not sure what you mean. The tests currently pass.
>>
>> My point was that our xml generation assumes an invalid revnum means
>> that thing isn't versioned. While added nodes now correctly report an
>> invalid revnum, they are versioned (or at least we've historically
>> treated them as such, even though they haven't yet been committed to
>> the repository).
>>
>> So spitting out "this thing is not versioned" isn't technically
>> correct, since the node is still under Subversion's control, but it's
>> the best we do right now. I claim the problem is orthogonal to the
>> above change, and should be fixed in the command line client.
>
> You updated the xml test to match the bad output. I think the test
> should be marked XFail (and the output change reverted) until we can
> get the cmdline client fixed to provide the proper output for added
> nodes.
Ah, now I understand.
In my opinion, the current output is just as bogus as before (if more
verbose), so there does not exist a regression. In other words, the
test has been PASS'ing for quite some time, even though it reported
these same nodes as rev=0, which is obviously bogus. If it PASS'd
under those conditions, why not now?
Also, while I'm not planning on fixing this long-standing issue with
the command line client imminently, I'd still like the tests to pass
so as to catch other issues which may come up as I muck with info.
-Hyrum
Re: svn commit: r1099193 - in /subversion/trunk/subversion:
libsvn_client/deprecated.c libsvn_wc/info.c tests/cmdline/info_tests.py
Posted by Greg Stein <gs...@gmail.com>.
On Tue, May 3, 2011 at 15:35, Hyrum K Wright <hy...@hyrumwright.org> wrote:
> On Tue, May 3, 2011 at 2:24 PM, Greg Stein <gs...@gmail.com> wrote:
>> On Tue, May 3, 2011 at 15:04, <hw...@apache.org> wrote:
>>> Author: hwright
>>> Date: Tue May 3 19:04:24 2011
>>> New Revision: 1099193
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1099193&view=rev
>>> Log:
>>> For info, don't fake a completely bogus revision for added nodes, just
>>> report an invalid revision.
>>>
>>> In updating the tests, I noticed we report "Resource is not under version
>>> control" in the XML for nodes with invalid revnums. While this isn't
>>> strictly true for added nodes, I'll leave that fix for future change.
>>
>> Eh? Shouldn't those tests be marked with XFail, rather than BAD OUTPUT?
>
> I'm not sure what you mean. The tests currently pass.
>
> My point was that our xml generation assumes an invalid revnum means
> that thing isn't versioned. While added nodes now correctly report an
> invalid revnum, they are versioned (or at least we've historically
> treated them as such, even though they haven't yet been committed to
> the repository).
>
> So spitting out "this thing is not versioned" isn't technically
> correct, since the node is still under Subversion's control, but it's
> the best we do right now. I claim the problem is orthogonal to the
> above change, and should be fixed in the command line client.
You updated the xml test to match the bad output. I think the test
should be marked XFail (and the output change reverted) until we can
get the cmdline client fixed to provide the proper output for added
nodes.
Cheers,
-g
Re: svn commit: r1099193 - in /subversion/trunk/subversion:
libsvn_client/deprecated.c libsvn_wc/info.c tests/cmdline/info_tests.py
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Tue, May 3, 2011 at 2:24 PM, Greg Stein <gs...@gmail.com> wrote:
> On Tue, May 3, 2011 at 15:04, <hw...@apache.org> wrote:
>> Author: hwright
>> Date: Tue May 3 19:04:24 2011
>> New Revision: 1099193
>>
>> URL: http://svn.apache.org/viewvc?rev=1099193&view=rev
>> Log:
>> For info, don't fake a completely bogus revision for added nodes, just
>> report an invalid revision.
>>
>> In updating the tests, I noticed we report "Resource is not under version
>> control" in the XML for nodes with invalid revnums. While this isn't
>> strictly true for added nodes, I'll leave that fix for future change.
>
> Eh? Shouldn't those tests be marked with XFail, rather than BAD OUTPUT?
I'm not sure what you mean. The tests currently pass.
My point was that our xml generation assumes an invalid revnum means
that thing isn't versioned. While added nodes now correctly report an
invalid revnum, they are versioned (or at least we've historically
treated them as such, even though they haven't yet been committed to
the repository).
So spitting out "this thing is not versioned" isn't technically
correct, since the node is still under Subversion's control, but it's
the best we do right now. I claim the problem is orthogonal to the
above change, and should be fixed in the command line client.
-Hyrum
Re: svn commit: r1099193 - in /subversion/trunk/subversion:
libsvn_client/deprecated.c libsvn_wc/info.c tests/cmdline/info_tests.py
Posted by Greg Stein <gs...@gmail.com>.
On Tue, May 3, 2011 at 15:04, <hw...@apache.org> wrote:
> Author: hwright
> Date: Tue May 3 19:04:24 2011
> New Revision: 1099193
>
> URL: http://svn.apache.org/viewvc?rev=1099193&view=rev
> Log:
> For info, don't fake a completely bogus revision for added nodes, just
> report an invalid revision.
>
> In updating the tests, I noticed we report "Resource is not under version
> control" in the XML for nodes with invalid revnums. While this isn't
> strictly true for added nodes, I'll leave that fix for future change.
Eh? Shouldn't those tests be marked with XFail, rather than BAD OUTPUT?
-g