You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Kevin Pilch-Bisson <ke...@pilch-bisson.net> on 2002/05/24 16:04:48 UTC
ra vtable do_merge function?
Hey,
In continuing to work on ra_pipe, I went to take a look at the do_merge
functions in ra_local and ra_dav, and found that there weren't any. Both ra's
just pass null as the vtable pointer, and no code in subversion ever calls
do_merge. Should prototype be removed from the vtable interface, or is there
a reason to keep it?
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: ra vtable do_merge function?
Posted by cm...@collab.net.
Kevin Pilch-Bisson <ke...@pilch-bisson.net> writes:
> > I *think* the prototype can go. I believe I added that when we first
> > started talking about doing merge, but before sussman settled on a
> > design for it. If `svn log' shows that indeed, that was my addition,
> > then you have my blessing on removing it.
> >=20
>
> Consider it gone.
Thanks, dude.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ra vtable do_merge function?
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Fri, May 24, 2002 at 11:07:40AM -0500, cmpilato@collab.net wrote:
> Kevin Pilch-Bisson <ke...@pilch-bisson.net> writes:
>
> > In continuing to work on ra_pipe, I went to take a look at the do_merge
> > functions in ra_local and ra_dav, and found that there weren't any. Both r=
> > a's
> > just pass null as the vtable pointer, and no code in subversion ever calls
> > do_merge. Should prototype be removed from the vtable interface, or is the=
> > re
> > a reason to keep it?
>
> I *think* the prototype can go. I believe I added that when we first
> started talking about doing merge, but before sussman settled on a
> design for it. If `svn log' shows that indeed, that was my addition,
> then you have my blessing on removing it.
>
Consider it gone.
$ svn log -r 1021 subversion/include/svn_ra.h
------------------------------------------------------------------------
rev 1021: cmpilato | Tue 22 Jan 2002 13:18:05 | 16 lines
* subversion/include/svn_ra.h
(svn_ra_plugin_t): Make docstring style for 'get_log' and
'check_path' consistent with others in this file. Added 'do_merge'
vtable item.
* subversion/libsvn_ra_dav/session.c
(dav_plugin): Added NULL placeholder for soon-to-arrive
svn_ra_dav__do_merge function.
* subversion/libsvn_ra_local/ra_plugin.c
(ra_local_plugin): Added NULL placeholder for soon-to-arrive
do_merge function.
------------------------------------------------------------------------
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: ra vtable do_merge function?
Posted by cm...@collab.net.
Kevin Pilch-Bisson <ke...@pilch-bisson.net> writes:
> In continuing to work on ra_pipe, I went to take a look at the do_merge
> functions in ra_local and ra_dav, and found that there weren't any. Both r=
> a's
> just pass null as the vtable pointer, and no code in subversion ever calls
> do_merge. Should prototype be removed from the vtable interface, or is the=
> re
> a reason to keep it?
I *think* the prototype can go. I believe I added that when we first
started talking about doing merge, but before sussman settled on a
design for it. If `svn log' shows that indeed, that was my addition,
then you have my blessing on removing it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org