On Sep 26, 2009, at 3:02 AM, Bert Huijben wrote:
>> -----Original Message-----
>> From: Hyrum K. Wright [mailto:hyrum_at_hyrumwright.org]
>> Sent: zaterdag 26 september 2009 2:51
>> To: svn_at_subversion.tigris.org
>> Subject: svn commit: r39616 - in trunk/subversion: libsvn_client
>> tests/cmdline
>>
>> Author: hwright
>> Date: Fri Sep 25 17:51:15 2009
>> New Revision: 39616
>>
>> Log:
>> Make 'svn info' use the baton-less entry crawler. This also has the
>> side-effect of returning the absolute path back through the info
>> callback.
>>
>> * subversion/tests/cmdline/changelist_tests.py
>> (info_with_changelists): Expect an absolute path.
>>
>> * subversion/tests/cmdline/basic_tests.py
>> (basic_info): Same.
>>
>> * subversion/tests/cmdline/info_tests.py
>> (info_on_added_file): Same.
>
> I think this change breaks a lot of user scripts that expected to
> see the
> path that they passed here. We can add an absolute path line if we
> like. The
> status apis had the same internal change, but they still provide
> identical
> relative paths to its users.
Nowhere in our API do we promise that the path returned on the Path:
line will be relative or absolute. We just claim that it will be a
path to the item. If people were relying on some implicit guarantee
that that path would be relative to some root, I don't think they have
a valid complaint.
I'd like to avoid info-item-proliferation if at all possible, and
given the lack of explicit absoluteness in the docs about the Path:
line, I don't think we need to add an additional line.
>>
>> * subversion/libsvn_client/info.c
>> (build_info_from_entry): Rename to...
>> (build_info_for_entry): ...this, and update to implement the correct
>> callback
>> type. Merge the error handling code into this function.
>> (info_error_handler): Remove.
>> (crawl_entries): Update to call the node walker.
>> (entry_walk_callbacks): Remove.
>> (svn_client_info2): Call crawl_entries() with an absolute path.
>
> And I know at least a few of my own scripts aren't going to like info2
> returning relative paths. I think there will be hundreds/thousands
> more.
>
> I think we should make svn_client_info2() pass relative paths again
> as a
> compatibility wrapper and introduce a svn_client_info3() for this
> and other
> changes. (E.g. the new conflicts stuff).
Yeah, we're going to have to rev the info interface anyway, for the
reasons you describe as well as the fact that the existing one is
pretty much a rebranded entry_t. I've got no issue with explicitly
declaring the returned path as absolute in the new callback, and I see
that you've implemented this in r39618.
(Wow, things sure are moving fast! A guy commits something before
going to sleep, and he wakes up to find his bugs fixed. :) )
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2400538
Received on 2009-09-26 14:58:14 CEST