Gavin 'Beau' Baumanis <gavin_at_thespidernet.com> writes:
> I started writing this email a little while back when I first started
> reading the thread,
> Subversion 1.5, Technology Preview - started by EPG.
>
> 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.
> Was is the architecture / application model - or the release model? -
> I don't know... and so for a while I sat on releasing my email - so as
> to not to come across as some newbie with absolutely no idea.
>
> Mind you, I have decided that I am pretty comfortable with the tag of
> newbie - since I am completely new... and quite simply do have no
> idea.
> None the less, despite not knowing exactly what model you were all
> talking about - I think my question is still valid none the less.
> Please find my original email below.
>
>
> Hi Everyone,
>
> Let me just start with;
> I am pretty naive as to the inner working of SVN (and the process for
> getting development done).
>
> I have at best intermediate skills as a SVN user and even less with
> respect to administration and I certainly understand the business
> realities of my next line too - so the cost (manpower and money) isn't
> lost on me at all...
>
> But surely, if the 'model' is broken - should it not just be fixed? -
> or even rewritten outright?
>
> I have been reading through the archive recently (working on my quest
> to collate the 'obliterate' use-cases) and I have noticed a few times
> that the explanation is along the lines of;
> "That's just the way it is".
> Sure there is a valid reason for it being that way;
> * Too hard to correct,
> * Too time consuming and
> * Quite often simply just not technically possible).
>
> (and I am leaving out the requests, where a user's request could be
> successfully performed with existing commands and some education about
> SVN).
>
> But if a user has a solid request, and the developers also agree the
> request is a solid one too;
> Then shouldn't a response like, "We can do it because of the current
> design - work around it by doing 'A', and 'B'.", trigger something
> more substantial?
>
> It has been such a long time since the original design was completed.
> The use-cases are now more complex and varied - and move outwards from
> the original core design, in ways no one ever though of two years ago
> -
> let alone from the original design of SVN as a whole.
>
> Thus, my (naive) question is;
> Is it time to re-design the SVN model and "fix" the underlying
> gotchyas that stop some of the ideas from even getting off the ground?
I don't mean to be discouraging or mean, Gavin, but I think a mail
like this has to be a *lot* more specific to be useful.
Whatever model we have, there will always be dissatisfactions of one
sort or another with it. This is true of any program. I think many
of the discussions you're referring to boil down to two "models": the
current working copy design (not model really, just design), and our
branching model.
Everyone agrees that the working copy code needs to be reworked to use
a centralized metadata model, and that many things will become easier
after that's done. There's little controversy there, it's just a
matter of finding resources.
There is more controversy around the branching model: whether it has
to change, if so then how, etc. But I think even there there is some
consensus that various things in Subversion would be easier if
Subversion were aware of branches as first-class objects, distinct
from copies. That doesn't mean the "branch-as-copy" implementation
needs to change, but it does mean that branching would need to do more
than just make a copy. I'm not sure this counts as a change of model
or not, but anyway it's being discussed.
I guess there's also the centralized vs distributed model, but those
terms by themselves are too vague to be useful without further
clarification. There are certain advantages to having certain bits of
repository history available on the client side (with regards to
merge-tracking, for example), and we may make those changes.
But saying "There's all this talk about models being restrictive, so
maybe we should change the model" is only useful as a prelude to a
specific technical proposal. As a general philosophical position, it
is both obvious and nugatory :-). "If it ain't broke, don't fix it;
and if it am broke, do fix it!" is a sentiment few would disagree
with, but also doesn't suggest any particular course of action.
Best,
-Karl
---------------------------------------------------------------------
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 16:31:45 CET