>So I think this problem should simply be declared "will not solve".
>
Nope. Will not solve in 1.0 for pragmatic reasons. _Will_ solve in the
future, also for pragmatic reasons -- these days, a changeset engine is
the only viable solution to source management on large, complex projects.
One of the things I've been hoping to call svn developers' (and
potential users) attention to is that a changeset engine is not
naturally layered over a version control system which is not a
changeset engine. (For example, Larry McVoy has oft repeated that it
took an amazing _$12M_ to build BK whose storage management strategy
predates changeset management concepts -- a slightly biased
characterization of his statements, but not completely unfair. Indeed
- so far as I know, the (imprecisely defined) distinction between
"changeset management" and "version control" originates with Larry.)
Changeset manipulation has implications all the way down. Once you
adopt it as an important design concern, it can guide your decisions
about storage management, often in simpler directions (e.g., file
properties are not needed or desirable -- so questions about how they
should work can be avoided). In the case of svn, it looks to me like
you need less work than what you're doing and planning, but then some
things that are different from what you're doing.
In other words, your "pragmatic reasons" don't appear to be very
pragmatic, from where I sit.
(I do feel a little two-faced here -- in plenty of contexts I'd argue
that svn-style storage mgt isn't needed _at all_ -- but the truth is
probably somewhere in between, this _is_ the svn list, and, anyway,
the political and economic positioning of svn can't be ignored -- so
I'll defer.)
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 14 06:08:38 2002