Changing svn_delta_editor_t

[Garrett Rooney <ro...@electricjellyfish.net>]

So as part of the atomic renames work I'm going to need to modify
svn_delta_editor_t.  Forget about the details of the change for now,
as the specifics are somewhat in flux, but in any event we will have
to add new functions to the vtable, which is declared in a public
header file and thus has its size exposed for the world to see.

Note that this is a prerequisite before any fs-atomic-renames code can
be merged into trunk, because it's required in order to make dump and
load work in the face of renames in a repository.

Now normally I'd say we're sort of screwed, since we declared the
structure publicly we can't change its size without breaking people,
so we have to rev it.  Ick.  But in this case that isn't so clear.  We
have a number of structures that we declare publicly but provide
constructors that the user is required to use when allocating them. 
svn_delta_editor_t in fact has such a constructor
(svn_delta_default_editor), and it was added for PRECISELY this reason
back when we were adding new functions to the structure and didn't
want things to break in code that allocates one.

Unfortunately, we never actually documented that
svn_delta_default_editor was the only correct way to allocate an
editor.  So there are quite possibly people out there who aren't using
it.  I haven't actually looked at any external consumers of the
Subversion codebase to see if anyone has fallen into this trap, but
it's certainly possible that they have.

So what do people thing?  Can we assume that people have been smart
and used the constructor?  Or are we stuck reving one of our most
central data structures?

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Changing svn_delta_editor_t

[Garrett Rooney <ro...@electricjellyfish.net>]

On 4/4/06, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> On 4/4/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> > /me is starting to lean towards just making the thing public and
> > documenting that you MUST use the constructor...
>
> +1.  -- justin

See r19194 for my first cut of this.

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Changing svn_delta_editor_t

[Justin Erenkrantz <ju...@erenkrantz.com>]

On 4/4/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> /me is starting to lean towards just making the thing public and
> documenting that you MUST use the constructor...

+1.  -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Changing svn_delta_editor_t

[Garrett Rooney <ro...@electricjellyfish.net>]

On 4/4/06, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> On 3/31/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> > work once I've had some time to play with some ideas.  If we're gonna
> > change it, might as well see if we can incrementally improve some
> > stuff while we're messing with it.
>
> My pet peeve is that the paths to the editors must be relative to the
> root instead of relative to the parent dir.  That annoys me to no
> end...

That would be awfully nice.  I'll keep in in mind.

In other related news, I've been playing around with making an opaque
editor interface, and OMG is it a pain in the neck.  All the function
names end up being ridiculously long, and the accessor functions are
worse, since either you have to typedef out individual callback types
for them, or you have to declare them inline, both options of course
suck, because their callbacks are either insanely long names or
insanely long declarations inline due to the number of arguments!

/me is starting to lean towards just making the thing public and
documenting that you MUST use the constructor...

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Changing svn_delta_editor_t

["C. Michael Pilato" <cm...@collab.net>]

Justin Erenkrantz wrote:
> On 3/31/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> 
>>work once I've had some time to play with some ideas.  If we're gonna
>>change it, might as well see if we can incrementally improve some
>>stuff while we're messing with it.
> 
> 
> My pet peeve is that the paths to the editors must be relative to the
> root instead of relative to the parent dir.  That annoys me to no
> end...  -- justin

I have this strange memory that it *used* to be the case that they were
relative to the parent directory, and then we intentionally changed it to
the current behavior.  The name "Greg" is attached to that memory, though I
dunno if it is a Hudsony or a Steinish flavor thereof...

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Re: Changing svn_delta_editor_t

[Justin Erenkrantz <ju...@erenkrantz.com>]

On 3/31/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> work once I've had some time to play with some ideas.  If we're gonna
> change it, might as well see if we can incrementally improve some
> stuff while we're messing with it.

My pet peeve is that the paths to the editors must be relative to the
root instead of relative to the parent dir.  That annoys me to no
end...  -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Changing svn_delta_editor_t

[Garrett Rooney <ro...@electricjellyfish.net>]

On 3/31/06, Branko Čibej <br...@xbc.nu> wrote:
> Garrett Rooney wrote:
> > So what do people thing?  Can we assume that people have been smart
> > and used the constructor?
> "Can we assume that people have been smart ..."
>
> Read that over again, and see if the answer isn't obvious ... :(

Yeah, I know, I know...

> >   Or are we stuck reving one of our most
> > central data structures?
> >
> We do have an alternative. It's called svn-2.0.
>
> The question is, can we afford to wait for atomic renames for another
> /N/ months? Or years? And do you want to throw most of the branch work
> away? (That's assuming that svn-2.0 has a new fs schema that isn't quite
> as brain-dead as the current one.)
>
> I sort of suspect that the answer to that one is obvious, too ...

Yep, looks like we're reving the editor interface!

I'll put together a better proposal on how the new interface would
work once I've had some time to play with some ideas.  If we're gonna
change it, might as well see if we can incrementally improve some
stuff while we're messing with it.

-garrett

Re: Changing svn_delta_editor_t

[Branko Čibej <br...@xbc.nu>]

Garrett Rooney wrote:
> So what do people thing?  Can we assume that people have been smart
> and used the constructor?
"Can we assume that people have been smart ..."

Read that over again, and see if the answer isn't obvious ... :(

>   Or are we stuck reving one of our most
> central data structures?
>   
We do have an alternative. It's called svn-2.0.

The question is, can we afford to wait for atomic renames for another 
/N/ months? Or years? And do you want to throw most of the branch work 
away? (That's assuming that svn-2.0 has a new fs schema that isn't quite 
as brain-dead as the current one.)

I sort of suspect that the answer to that one is obvious, too ...

-- Brane



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org