Kevin Pilch-Bisson <kevin@pilch-bisson.net> writes:
> I can't think of anything. However, I do have a question. How are we going
> to deal with printing binary props? Currently we just printf the property
> value, which won't work for binary properties.
I don't know, but we don't need to decide now (there are lots of
things that need to happen for, say, i18n). The important thing is
that that problem remain restricted to client implementations --
internally, the libraries must support binary props.
> > /* Set *PROPS to a hash table whose keys are `char *' paths
> > * indicating the relative path from TARGET to a node on which
>
> Actually, the keys represent the relative path from where the command is
> called. The path starts as TARGET, and gets new filename or dirnames added
> to it as it recurses. Should I state:
>
> "whose keys are `char *' paths indicating the relative path, including TARGET,
> to a node on which property PROPNAME is set" ?
>
> Alternatively, the function could be modified to perform as your docstring
> suggests.
Having returned values be dependent on cwd is very rare in Subversion.
The more usual behavior is like I described, or even better: the paths
should just include TARGET as prefix. That way, everything behaves
quite intuitively: for example, you ask for prop X on file F, and you
get back a hash with key F and some value.
Or relative to TARGET, or whatever. The important thing is that
TARGET determines what those returned paths look like, not some
external factor. The external cwd factor may still determine how
TARGET gets *interpreted*, but that's fine & standard practice. Think
of `ls', for example:
newton$ ls -l README
-rw-r--r-- 1 kfogel users 2175 Oct 25 11:13 README
newton$ ls -l ../subversion/README
-rw-r--r-- 1 kfogel users 2175 Oct 25 11:13 ../subversion/README
newton$ ls -l /home/kfogel/src/subversion/README
-rw-r--r-- 1 kfogel users 2175 Oct 25 11:13 /home/kfogel/src/\
subversion/README
It's the same file every time, but `ls' returns its name according to
how I asked for it. Subversion's libraries all work the same way.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:48 2006