On Tue, 14 Dec 2004, VK Sameer wrote:
> On Tue, 2004-12-14 at 14:35, Peter N. Lundblad wrote:
> > On Tue, 14 Dec 2004, VK Sameer wrote:
> >
> > +
> > +svn_error_t*
> >
> >
> > Space after *.
>
> Hmm, didn't see it, unless you meant before? Did add that.
>
Good. Maybe better to read my mind than my mail. ;)
> > Index: subversion/libsvn_ra_local/ra_plugin.c
> > ===================================================================
> > --- subversion/libsvn_ra_local/ra_plugin.c (revision 12257)
> > +++ subversion/libsvn_ra_local/ra_plugin.c (working copy)
> > @@ -688,6 +688,9 @@
> > svn_fs_root_t *root;
> > const char *abs_path = sbaton->fs_path;
> >
> > + if (path)
> > + SVN_ERR (svn_path_check_valid (path, pool));
> > +
> >
> >
> > svn_ra_plugin_t->check_path, which this implements, takes a path, checks
> > if it exists (in a particular revision) and what kind it is. So you don't
> > need the above.
>
> OK, thanks for double-checking the call sites.
>
As I might have said before, I'd like you to put these checks in the
servers as well, so some other client doesn't get invalid paths in by
mistake. That can be a different patch if you want.
> > I see that you are adding the checks to both libsvn_wc and libsvn_client.
> > Isn't it enough to add them to libsvn_wc (except in the import code)? For
> > example, wc_to_wc_copy it seems redundant. Or maybe you are plugging some
> > hole somewhere else?
>
> No, I haven't found a hole. Initially, the plan was to put the checks
> only in the libsvn_client layer to catch errors as close to the user as
> possible. Since I hadn't reviewed all the paths carefully, I added
> libsvn_wc based on Jon's patch. If libsvn_wc is a better layer in terms
> of greater coverage in fewer call sites, I can remove the checks from
> the libsvn_client layer.
>
I'm not sure what would yield the least number of call sites. YOu should
be consistent, though. PUtting most checks in libsvn_wc would make sure
other users of that library (if there are any) won't add such paths by
mistake.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 14 12:31:27 2004