>> To put it pessimistically: it's (at least):
>> 1) too complicated
>> How? That's a vague generalization. Could you please be
>> more specific?
Yes, it's vague. There's the LOC count of the core components;
there's the number of relatively new external packages it depends on;
there's the fact that it smashes together, seemingly monolithically,
functionality that I thing ought to be layered (e.g. apache and webdav
integration).
I see (and have demonstrated) simpler approaches. Experience tells me
svn is too complicated.
>> Subversion isn't focused on distributed repositories. They're out of
>> scope atm.
Perhaps.
Personally, I think distribution is fairly trivial, once the other
fundamentals are in place. That distribution appears too difficult to
consider for 1.0 is a sign, to me at least, that in svn, the
fundamentals are not in place.
>> 4) peculiar (at best) user interface
>> The only great interface to a complicated SCM system is likely to be
>> several interlated GUI tools.
?
>> Additionally, is this a complaint about
>> Subversion's command line calling a "branch" a copy?
No. It's based on observations such as:
1) With subversion, a working tree is not the same thing
as a source tree.
2) You have to use svn-specific tools to create, rename, or
delete files.
3) The interface bends over backwards to preserve the feel
of revisioned files rather than revisioned trees.
One can argue that users will not accept anything but a CVS-workalike,
but I do not find such cliches persuasive -- they set off red flags
for me, actually. From what I've seen, you've even convinced a lot
of prospective users with such cliches.
>> 5) questionable storage manager semantics
>> Which ones? Using BDB, our working copy model? Etc...
We would have to have that patch set discussion in detail.
Aside from that, how is using BDB a semantic issue? I thought that it
was an implementation technique.
> It's very modular, the entire repository access mechanism is
> abstracted.
The introduction of abstractions is not the same thing as modularity.
With arch, I can and have swapped around major subcomponents easily
and to good effect and, should I ever get back to work on it, expect
to do more of that.
It's another vague distinction. My modules are less tightly coupled
than yours; the burden associated with swapping a component is
comparatively high.
>> 3) that hits an interesting sweet spot,
>> performance/complexity-wise.
>> It's probably too soon, to tell about that, but we hope so.
Well, I think you've done a hell of a lot of work so far for that to
still be an open question.
> * Our working copy code base needs some help from the bottom up.
> It can't handle chained renames, botching it into shape so that the
> merge history problem is agreeable is going to be fun. It also seems
> like the WC entry caching change is going to be a huge change as
> well.
Part of the reason I gave up on svn a few years back was precisely
because I could not see any good solution to this problem.
> * The merge history issue needs a decent resolution.
> Even if we don't use merge ancestry set information, merge-copies
> barf if we naively add the source merge files into the working copy.
> (issue 838)
I don't understand the details of this comment. I think it is a
mistake to store merge history (solely) in the repository -- for
various reasons, it works out nicely to store it in the trees
themselves. There is a general design principle behind that ("all
meta-data goes in the trees, in parsable plain text") but there is no
single pithy argument that justifies that principle.
> * svndiff (our delta format) isn't very "cvs annotate" friendly.
> This is really depressing, esp. after Brane spent a lot of hard work
> writing a delta combiner for us. :( Thoughts about how to handle the
> delta-window problem wrt svndiff would be most welcome.
I think arch-style revision libraries are the current best way to go
here. Better file systems in the next few years will yield other
approaches. If you want to be BSD specific, you could just use
directory stacks.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 13 06:36:37 2002