You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Hyrum K Wright <hy...@hyrumwright.org> on 2012/11/27 13:49:04 UTC

[RFC] Ev2 implementations in ev2 subdirectory

Greetings all!

r1413184 introduced the --enable-ev2-impl flag to configure on trunk to
allow interested users to compile with the Ev2 implementations of various
operations.  While the set of things that supports Ev2 is not nearly
complete, it is (slowly) growing, and I'd like to do that development on
trunk, rather than the current ev2-export branch.

To that end, I plan on selectively moving the current bits from the
ev2-export branch to trunk, guarded by this configure-time flag.  I also
hope to add a buildslave which runs the tests with --enable-ev2-impl to
catch failures soon after they are introduced.

For the immediate future I'd like for this code to be compiled, but not in
the call path by default.  We can use #ifndef guards, but that means the
code won't even be compiled.  If we unconditionally compile the code in the
same file, we get unused symbol warnings, and have to worry about clashing
function names (Ev1 add_directory vs. Ev2 add_directory).  It also creates
something of a mess for people trying to determine which code is actually
being used.

Instead, I propose subdirectories named ev2 in the various libsvn_foo
directories which would hold Ev2 implementations.  They would eventually go
away if/when the Ev2 implementations replace the existing ones.  We haven't
historically used subdirectories in this way, but I think this type of
change would make implementation and maintenance easier.

Thoughts?

-Hyrum

Re: [RFC] Ev2 implementations in ev2 subdirectory

Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Tue, Nov 27, 2012 at 9:21 AM, Daniel Shahaf <d....@daniel.shahaf.name>wrote:

> Hyrum K Wright wrote on Tue, Nov 27, 2012 at 09:11:50 -0500:
> > On Tue, Nov 27, 2012 at 9:07 AM, Daniel Shahaf <d.s@daniel.shahaf.name
> >wrote:
> >
> > > Hyrum K Wright wrote on Tue, Nov 27, 2012 at 07:49:04 -0500:
> > > > Instead, I propose subdirectories named ev2 in the various libsvn_foo
> > > > directories which would hold Ev2 implementations.  They would
> eventually
> > > go
> > >
> > > Not objected to subdirs, but have you considered just naming your files
> > > libsvn_repos/ev2_replay.c and so on?  That doesn't need any build.conf
> > > changes...
> > >
> >
> > I thought about that, but didn't want to double the number of files in
> > something like libsvn_client where there are several editor
> implementations.
> >
> > I know we already have subdirectories in at least a couple of places
> > (mod_dav_svn comes to mind).  Are the build.conf changes that invasive?
>
> No, they aren't invasive; they're just one more moving part --- and I've
> spent the last couple of days reducing the number of moving parts (in
> various other contexts), so I quite appreciate the difference between
> "0. Profit!" and "0. Foo 1. Profit!".


I completely understand (and agree!), but I think in this case it'd be
worth it to make the segregation more pronounced by using the
directory hierarchy as a namespace mechanism, rather than prepending
something to the filename.

-Hyrum

Re: [RFC] Ev2 implementations in ev2 subdirectory

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Hyrum K Wright wrote on Tue, Nov 27, 2012 at 09:11:50 -0500:
> On Tue, Nov 27, 2012 at 9:07 AM, Daniel Shahaf <d....@daniel.shahaf.name>wrote:
> 
> > Hyrum K Wright wrote on Tue, Nov 27, 2012 at 07:49:04 -0500:
> > > Instead, I propose subdirectories named ev2 in the various libsvn_foo
> > > directories which would hold Ev2 implementations.  They would eventually
> > go
> >
> > Not objected to subdirs, but have you considered just naming your files
> > libsvn_repos/ev2_replay.c and so on?  That doesn't need any build.conf
> > changes...
> >
> 
> I thought about that, but didn't want to double the number of files in
> something like libsvn_client where there are several editor implementations.
> 
> I know we already have subdirectories in at least a couple of places
> (mod_dav_svn comes to mind).  Are the build.conf changes that invasive?

No, they aren't invasive; they're just one more moving part --- and I've
spent the last couple of days reducing the number of moving parts (in
various other contexts), so I quite appreciate the difference between
"0. Profit!" and "0. Foo 1. Profit!".

> 
> > away if/when the Ev2 implementations replace the existing ones.  We
> > haven't
> > > historically used subdirectories in this way, but I think this type of
> > > change would make implementation and maintenance easier.
> > >
> > > Thoughts?
> > >
> > > -Hyrum
> >

Re: [RFC] Ev2 implementations in ev2 subdirectory

Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Tue, Nov 27, 2012 at 9:07 AM, Daniel Shahaf <d....@daniel.shahaf.name>wrote:

> Hyrum K Wright wrote on Tue, Nov 27, 2012 at 07:49:04 -0500:
> > Instead, I propose subdirectories named ev2 in the various libsvn_foo
> > directories which would hold Ev2 implementations.  They would eventually
> go
>
> Not objected to subdirs, but have you considered just naming your files
> libsvn_repos/ev2_replay.c and so on?  That doesn't need any build.conf
> changes...
>

I thought about that, but didn't want to double the number of files in
something like libsvn_client where there are several editor implementations.

I know we already have subdirectories in at least a couple of places
(mod_dav_svn comes to mind).  Are the build.conf changes that invasive?

> away if/when the Ev2 implementations replace the existing ones.  We
> haven't
> > historically used subdirectories in this way, but I think this type of
> > change would make implementation and maintenance easier.
> >
> > Thoughts?
> >
> > -Hyrum
>

Re: [RFC] Ev2 implementations in ev2 subdirectory

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Hyrum K Wright wrote on Tue, Nov 27, 2012 at 07:49:04 -0500:
> Instead, I propose subdirectories named ev2 in the various libsvn_foo
> directories which would hold Ev2 implementations.  They would eventually go

Not objected to subdirs, but have you considered just naming your files
libsvn_repos/ev2_replay.c and so on?  That doesn't need any build.conf
changes...

> away if/when the Ev2 implementations replace the existing ones.  We haven't
> historically used subdirectories in this way, but I think this type of
> change would make implementation and maintenance easier.
> 
> Thoughts?
> 
> -Hyrum