[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: svn_client_status and path relativity

From: Bert Huijben <rhuijben_at_sharpsvn.net>
Date: Sun, 11 Oct 2009 23:36:50 +0200

> -----Original Message-----
> From: news [mailto:news_at_ger.gmane.org] On Behalf Of Roman Donchenko
> Sent: zondag 11 oktober 2009 22:19
> To: dev_at_subversion.tigris.org
> Subject: svn_client_status and path relativity
>
> Hello,
>
> While debugging the last Python testsuite failure, I've come upon an
> issue
> in the info implementation.
>
> First of all, as I've already mentioned in IRC, the receiver argument
> to
> svn_client_info3 is of type svn_info_receiver2_t in the function
> declaration, but svn_info_receiver_t in the definition. As both types
> are
> identical, it doesn't cause any problems, but I'm listing it here for
> the
> record.
>
> Later on, however, in the aforementioned function we have:
>
> SVN_ERR(receiver(receiver_baton, base_name, info, pool));
>
> Why are we passing it the base name here? The parameter is called
> abspath_or_url, presumably it expects to be passed an absolute path or
> a
> URL. 8=]
>
> Moreover, I'm not sure what should be passed there. If we pass the URL
> in
> the repository, then info_receiver_relpath_wrapper will be unable to
> transform it into a relative path for svn_client_info2 users. And if we
> use the absolute path in the WC, we still won't achieve full
> compatibility: previously, "svn info mywc/blah.txt -rHEAD" would return
> "blah.txt" as the path, now it would return "mywc/blah.txt". And I'm
> not
> sure which one is a better answer. The latter appeals to me more, but
> it's
> backwards incompatible.

The idea is that all new functions will only accept absolute paths for local
dirents. This allows cleaning up a lot of cod in our backend libraries
(read: libsvn_wc) on path handling. (One major issue is that there are an
infinite numbers to describe a path in relative form. Luckily there is just
one absolute path)

If a new function accepts a relative path for its operation and calls
callbacks you can easily transform the expected paths back to their relative
form. (See libsvn_client/deprecated.c and libsvn_wc/deprecated.c for dozens
of examples).

* Take the absolute path of the anchor/target argument...
* Pass this absolute value to the new function, with a wrapped callback.
* Store both the relative path and the absolute path in the baton.

In the callback:
* strip the absolute path from the start of the passed absolute path.
(svn_dirent_skip_ancestor() does this for you).
* Join the original relpath with the rest of the path. This brings you are
back in the relative format callers expect.

If you look at svn_client_info2() in subversion/libsvn_client/deprecated.c
(and its helper function info_receiver_relpath_wrapper()) you can see how
svn_client_info2() does this for its old users.
(It actually has a small optimization for callers that already pass absolute
paths)

        Bert

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2406443
Received on 2009-10-11 23:37:11 CEST

This is an archived mail posted to the Subversion Dev mailing list.