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

Re: Sparse directories - mini-review

From: Peter Lundblad <plundblad_at_google.com>
Date: 2007-03-15 21:02:00 CET

Malcolm Rowe writes:
> - ra_svn: In the 'update', 'switch', 'status', and 'diff' commands,
> we're adding the depth inside a tuple, whereas in the 'set-path' and
> 'link-path' cases we're not. The former matches what the extensibility
> parts of the protocol document suggest, but the latter makes more sense
> to me (I don't understand what the protocol document is saying here).
> Regardless, can we pick one approach?
>

The depth parameters to the svn_ra_ functions that give back a
reporter are supposed to go away. They are unnecessary. That's why I
didn't fix the ra_svn protocol stuff for those.

> - (This isn't exclusive to sparse-directories: changelist and keep-local
> do it too, but:) Why are we writing out the depth attribute in the
> old XML-format entries, when by definition it can never have any value
> other than the default? (Also note that the specification for the
> entries XML format prohibits unknown attributes, so this is
> technically wrong).
>
Yup. Good catch! I didn't notice that during my review.

> (Actually, could someone remind me why we even have the capability to
> write out the XML entries format? I'm sure there is a reason, but I
> can't remember what it is.)
>
We need to be able to cleanup a directory that hasn't yet been
upgraded to
the new format. Boring, but true.

Another thing I noted when I reviewed, but didn't bring up yet:
When functions are revised on this branch, *all* compatibility
wrappers are updated. That's not what we've been doing before. Is
there a specific reason for that? If not, I think that's bad idea
because it introduces code duplication in code that we test very
seldom. that's not a big deal when the wrappers are trivial, but
sometimes they aren't. This might be easier to get fixed befre the
branch is merged.

Thanks,
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 15 21:02:30 2007

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.