Actually, Subversion is broken in some ways. I don't think it's quite as
broken as you think though. :)
More information on what I think the current failings in Subversion are
after I comment on what you thought.
> From: Tom Lord [mailto:lord@regexps.com]
>
[....]
>
> My basic take on svn is that it has some good ideas and ok coding
> practices but a flawed design, perhaps from the ground up, or
> (optimistically?) in the details.
>
> To put it pessimistically: it's (at least):
> 1) too complicated
How? That's a vague generalization. Could you please be more specific?
> 2) depends on too many other pieces
> 3) too centralized
Subversion isn't focused on distributed repositories. They're out of
scope atm.
> 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?
> 5) questionable storage manager semantics
Which ones? Using BDB, our working copy model? Etc...
> A FS with cheap tree cloning is a good thing. The rest of it is
just,
> based on everything i've ever learned, pretty much wrong.
Like what?
>
> Again -- that's the *pessimistic* take.
>
> Optimistically, maybe it's:
>
> 1) more modular than it first appears
It's very modular, the entire repository access mechanism is abstracted.
> 2) with a storage manager that can be easily fixed and,
The API design was such where we tried to make BDB replaceable. Given
how wildy different such storage managers can operate the only real way
to tell is by implementing a separate one and seeing what breaks.
> 3) that hits an interesting sweet spot,
> performance/complexity-wise.
It's probably too soon, to tell about that, but we hope so.
Now that I've covered your comments here are my current annoyances with
Subversion atm:
* Renames/Moves aren't recorded intrinsically:
They're inelegantly represented as copy/delete pairs, and the
fact that a move initiated the copy/delete pair is not recorded.
* 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.
* 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)
* 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'm sure there are less annoying warts in Subversion atm, but those
strike me as among the worst.
FYI,
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 13 05:09:13 2002