> 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.
Absolutely. That's the key, some of the issues are smaller or have
obvious incremental points along the path of least-solution to
best-solution.
> 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.
The working copy isn't, at least as I understand the breadth of impact
on code, UI and tools, one of these small pieces. I doubt that, after
mapping out the use-cases, smarter tagging and branching will be
trivial either though I agree that it may well not be a rewrite of the
model but merely support for annotating folders as having
project-root, tag-hierarchy, tag, branch-hierarchy, branch and
default-branch meta-data.
> 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.
If an intent were expressed to support a fully distributed model I'd
think it would be more useful to transfer the development talent in
the Subversion project onto another project that is much further along
and try to transplant some of the things Subversion does that they
don't EG Subversion-->Bazaar could provide mime-type suppport,
properties support and EOL conversion.
> 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.
I don't think the direction of 'rewrite' vs 'fix' can be applied
generally. Each of the issues should be given it's own moment in the
spotlight and examined more carefully even if the result is just to
map out the points and counter-points of discussion so that any future
attempt to actually find a design solution doesn't have run over the
same ground repeatedly.
Perhaps a reasonable starting point is to re-list the major issues,
note any known development intentions and nominate a proponent
(volunteers welcome I'm sure) to deal with driving discussion on them
individually.
--
Talden
---------------------------------------------------------------------
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-02 01:39:00 CET