On Fri, 30 Sep 2005, Max Bowsher wrote:
> >On Fri, 30 Sep 2005, Chia-liang Kao wrote:
> >...
> >>Log:
> >>Fix check-swig-pl failures.
> >>
> >>* libsvn_repos/repos.c:
> >> (svn_repos_create) Allow fs_config to be null, as svn_repos.h says so.
>
>
> Sorry for not noticing that! Thanks for cleaning up after me, clkao.
>
>
> Daniel L. Rall wrote:
> >That would leave repos->fs_type uninitialized if fs_config was NULL. How
> >about this?
> ...
>
> No, clkao's original patch was correct.
Yeah, we discussed this on IRC -- I agree.
> What's currently committed has the flaw that when opening a non-default
> fs-type, repos->fs_type holds a meaningful but incorrect value for a while,
> instead of holding NULL (i.e. unknown) until the real data is known.
> I'll revert what was committed, commit clkao's patch instead, and propose
> for backport.
I can see how you might take that line of thinking, Max. However, I'm
missing the part about how the constructor function's creation of
svn_repos_t is flawed by setting fs_type to DEFAULT_FS_TYPE. In fact, with
that data type constructor function being a part of Subversion's public API,
it should return properly initialized data structures, where "properly
initialized" means that all default values are already set. It is
incohesive and overly coupled to rely on a subsequent function to set the
default value. I greatly prefer the r16366 version which you reverted
without discussion.
Thanks, Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 30 11:15:31 2005