(CC list trimmed, again.)
I don't work for CollabNet (I work for MIT, where my job has nothing to
do with Subversion); others can provide better insight into the working
environment there, if they so choose.
> From what I've seen on the dev list, that discussion could have
> reached a level where we were building models and proofs like that one
> i sent you
To make progress, we want good understandings between the people who
write the code. Most of the people who are writing the code probably do
not think best in terms of set-theoretic formalisms; less formal styles
of communication work better. If you look at, say,
http://svn.collab.net/repos/svn/trunk/subversion/libsvn_fs/structure,
you can see the kind of communication which our developers can all
understand. It is at the right level of conciseness.
Formalisms are not necessary clearer or even more precise than informal
descriptions. If you're going to prove something non-obvious, a
formalism can be useful, but once you've done your proof, I think we (a
group of mostly non-mathematicians) are better off with informal models.
> But instead, well, it's all "post 1.0"
This project has a goal, which is to provide a compelling CVS
replacement for the open source community. We are close to realizing
that goal. Standardizing on a patch set format with other version
control systems is not a requirement for that goal. Hence, it waits
until after 1.0. This isn't "technology taking a back seat to
business"; this is basic project management.
Now, if our model is so far off-base that we won't be able to support
some important future feature like repeated merges, that's a reason to
stop and think. You can see that we're actually doing that in the
"Issue 838 merge should copy-with-history" thread, because we believe
there might be a real problem.
> Regardless, arch is at least a very
> plausible indication that svn has a few fundamentals wrong (and
> perhaps some other fundamentals right).
Not by its mere existence, it isn't. There are a few steps missing in
this argument.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Aug 11 01:06:36 2002