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

Changing svn_delta_editor_t

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2006-03-31 23:52:32 CEST

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?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 31 23:56:50 2006

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