Re: How to get prop path for SVN_WC_THIS_DIR?

On 10/1/05, Philip Martin <philip@codematters.co.uk> wrote:
> Ivan Zhakov <chemodax@gmail.com> writes:
>
> > On 10/1/05, Philip Martin <philip@codematters.co.uk> wrote:
> >> Move the "ugly logic" into a function and have both places call it.
> > You really think so? For me removing path from computed path is
> > errorful and darkly:
> > <<
> > [snip]
> > const char *access_path = svn_wc_adm_access_path (adm_access);
> > int access_len = strlen (access_path);
> >
> > /* Empty path and paths ending in / don't need an extra slash removed */
> > if (access_len == 0 || access_path[access_len - 1] == '/')
> > slash = 0;
> > else
> > slash = 1;
> > [snip]
> > /* Compute pathnames for the "mv" log entries. Notice that these
> > paths are RELATIVE pathnames (each beginning with ".svn/"), so
> > that each .svn subdir remains separable when executing run_log(). */
> > tmp_props = apr_pstrdup (pool, local_prop_tmp_path + access_len + slash);
> > real_props = apr_pstrdup (pool, local_propfile_path + access_len + slash);
> >>>
> > Also this code assumes that how svn_wc__prop_path() makes it's path.
>
> Moving that code into a new function would seem to be an improvement;
> the new function could be put in the same file as svn_wc__prop_path.
Of course I could do so, but I consider that only svn_path_* functions
should know about slashes and etc?

> > Why we need interpret things that just joined? Why our wc code wories
> > about slash characters?
>
> I don't know, I didn't write that bit of code. Perhaps you could
> write a new function svn_wc__relative_prop_path, and get rid of it
> altogether?
It's seems acceptable solution for me, but is it not burden to have
another three functions svn_wc__relative_prop_path,
svn_wc__relative_base_prop_path, svn_wc__relative_revert_path() ? (Of
course all will be implemented using internal mega helper
prop_path_internal)

Also I don't understand why passing SVN_WC_ENTRY_THIS_DIR to
svn_wc_entry() is wrong?

--
Ivan Zhakov