No SQLite WAS: file://.... WAS BDB vs SQLite ...

Ok. Given all the discussion so far, anything other than a hack at the moment
is non-trivial. And the hack if we use it needs to be examined post-1.0.

Even using SQLite isn't going to work as a quick fix.

So can we go ahead and create a Patch Issue and allow for non-mainline dev
builds to offer this additional tweak?

For example - suppose the Mandrake RPM build set allowed for dev builds to
turn this option on. But any blessed builds would not incorporate this
obviously hacked together non-mainline code that still needs additional
testing anyway.

In the Mandrake build set, I would add code that looked for the patch being
presnet in the directory as well as a command line option when creating the
RPMs.

That way, the patch would never be part of the mainline distro, and users
would at least have to locate the patch to use it.

Or any other build set that someone wanted to allow users to create a dev
build to use this or similar methods.

That way, we could be using the same codebase, but at the same time have
additional users testing it if they so chose with little or no fuss.

The wider the audience the more likely bugs in the implementation will be
visible.

And as long as it's obvious it's not production code, no one should be getting
upset.

Thoughts? Would that satisfy everyone for the time being?

-- 
Shamim Islam
BA BS
Files said:
> kfogel@collab.net said:
>> I think our reactions are more about "Let's not add this complexity so
>> close to 1.0, let's revisit the issue afterwards" than anything else.
>> At least, that's my motivation.
>
> Ok. I'm with you on that. I'm for opening a Patch Issue that David can keep up
> to date, so when we're ready to discuss it post 1.0, we can implement it.
>
> Also, maybe if we could add it in a list of features that are planned, I would
> vote +2 if you let me. LOL
>
> That way we can come back and discuss it and have a viable place to start, AND
> David gets to have a current version of the code that works for him.
>
> And if anyone else wants to add it as a non-mainline option to build into
> subversion (read dev builds, not blessed builds), they can do so.
>
>> Well, the file:// protocol is useful for testing whether a given
>> behavior is independent of a network layer or not.  We do this all the
>> time.
>
> file:// is only supposed to be used for testing? Oops. I only use
> client-server when necessary.
> --
> Shamim Islam
> BA BS
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org