On Fri, Feb 16, 2001 at 06:24:11PM -0500, Greg Hudson wrote:
> (I realize this specific issue is moot at the moment, but the attitude
> behind it is important to me.)
Concretely, yah moot. In the abstract? Never moot, I'd think.
> > Then just pass --with-dbm=db1 to the APRUTIL configure. No big
> > deal. Chill.
>
> I still think it's a big deal. I don't think it's reasonable for
> packages to behave consistently in a multiplatform environment only if
> the builder understands issues like this and passes special configure
> flags. The builder may be having to deal with a lot of different
> packages; there's a reason why the gnu project tries to present a
> standard configuration interface for packages.
The "builder" in this case is SVN. It can always pass --with-dbm=sdbm to
APRUTIL and get the same code everywhere (SDBM is built right into APRUTIL).
But your meta-point is entirely valid.
> Also, let's say I build svn for our distributed environment with
> --with-dbm=ndbm for consistency, but someone mounts their homedir on
> their stock (let's say) Red Hat 10.2 system and uses the native svn
> client which was built with db3. They lose, for reasons they
> shouldn't ever have to understand. Not all of our users are going to
> be programmers, and even the ones who are would generally like their
> tools to be robust.
Presuming that SVN will always specify a single DBM because it wants to be
maximally useful in a multiplatform environment, then circumventing SVN's
choice is prone to badness. If somebody did that, then blame them.
APRUTIL currently defaults to SDBM, and I haven't put the autoselection
logic in for the very reasons you cite. It could be dangerous. But SDBM is
also a very weak implementation (very hard limits on record sizes).
If we don't make SVN define a DBM style for APRUTIL, then yes: we could
potentially run into situations like the above. I'm not sure it is our
fault, though. On my RH system, DB2 is the right choice; it just comes
standard. Only when I want to have a portable working dir, do I begin to
care. And note that *no* DBM has portable byte-ordering (that I know of). If
you used the working copy between a Sparc and an x86, you're just flat out
screwed.
[ and no: apr_dbm has no auto-detection or dynamic selection at this time;
excellent feature request which I had thought of, but not there now. I was
thinking about it to detect SDBM dbs that were compiled with different
record size limits. ]
> For the wc, we should either restrict ourselves to the lowest common
> denominator of functionality, or make the highest common denominator a
> hard requirement. Making the wc data format dependent on compile-time
> options is a recipe for disaster.
I'd take the LCD over anything more (and as pointed out, it should be fine
for us anyways). Not sure that I entirely agree with the second sentence,
but no matter.
> (Especially since we've made a number of design decisions based on the
> requirement of being able to take a wc subdirectory, move it from one
> place to another and back, and have it still work the whole time.)
Well... I'm not sure about "how far". Surely, move it around within a
filesystem on one machine. I never knew we planned to allow them to be truly
portable across systems; certainly not a requirement in my head.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:22 2006