It seems like all I post are "I don't understand" questions.
I get more confused every day.
This will help me a great deal.
Karl Fogel wrote:
> Bill, I'm sort of losing track of exactly what's being proposed and
> what its goals are, at this point.
> A *really* helpful thing would be a fresh mail, that begins with a
> list of the problems you're trying to solve, including a small
> concrete example for each problem. These should only be problems that
> exist in the current filesystem implementation, not problems in prior
> incarnations of various proposals. Describe solutions only after the
> problems are presented.
I assume you mean in a real "svn ...." context right?
> For example, you seem to want to treat branches as different from
> copies, but that's only something I've inferred slowly from your
> mails. Maybe there's a reason to do so, but right now branches and
> copies are just two words for exactly the same thing in Subversion.
> There's no difference, and distinguishing between them would be a
> major design change [read: unlikely before 1.0 :-), though if failure
> to distinguish leads to horrible problems, then of course we need to
> rethink]. Until we understand whether or not this is a goal, and if
> it is then why, it's hard to evaluate or even think clearly about the
thank you again.
> Just to be clear: I really, really appreciate that you're bringing
> years of db experience and schema design to bear on Subversion's
> problems, and want to benefit from this. But without clear
> communication, there's no way we'll grok the wonderful things going on
> in your head :-).
> Btw: I know it's much easier for you to speak in generic RDB language,
> and that you look forward to the day when Subversion uses a real
> relational database backend... But, as we are using Berkeley DB right
> now, and also in 1.0, so it would help a lot to talk about how things
> would be implemented in bdb specifically.
I totally agree here. When porting to "blah blah blah" it helps to always
have a point of reference.
It seems to me that BDB and the existing code have to be considered the
I'm not saying ignore SQL impacts to the schema; But it is hard to jump
back and forth between the future and the present.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed May 8 20:30:18 2002