On Sat, 2008-03-01 at 21:54 +1100, Gavin 'Beau' Baumanis wrote:
> But having read it a few times (the thread and my email - I still
> couldn't make up my mind as to what "model" you were all talking about -
> with respect to it being too restrictive to development.
It depends on who you're asking, but for the repository model, people
are talking about things like:
* We have a single linear sequence of revisions.
* We track file and directory copies.
* Copy ancestors do not have to be from the previous revision.
* We don't track renames; they are expressed as copy + delete.
* We don't track branches; they are expressed as copies.
* We don't track tags; they are expressed as copies.
* We aren't a distributed SCM.
There's a certain elegance in the model, but when it comes to doing
smart merging, it's not always clear what the user intention of a copy
was and what to do with it.
The working copy model has its own issues, chief among them that it has
per-directory metadata like CVS. This allows working copy subdirs to be
"severed" from a checkout, but poses efficiency issues for large working
copies. The API is also historically dissatisfying to developers for
complicated reasons.
That's a really oversimplified summary of the issues people have been
running into with some of the 1.5 features, I'm sure.
> But surely, if the 'model' is broken - should it not just be fixed? -
> or even rewritten outright?
All software winds up being kind of dissatisfying once it's mature.
It's often easier to live with them.
There's always been a sense that at some point the Subversion community
should take its learnings and design a Subversion 2.0 which is partially
or completely incompatible with Subversion 1.x. But it's a huge task.
Partially because if you're going to make such a dramatic break, you
don't want to solve just one of the many compatibility issues, and no
one person is prepared to solve them all.
There's also the question of whether there's another version control
system out there which already has a better model, and whether it would
be better to contribute to giving them more polish (Subversion's
popularity is partly due to having a good Windows port, for instance)
than to design a new system which bears the Subversion name.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-03-01 23:00:21 CET