>> Is dump/restore guaranteed to be cross version? i.e.,
>> current version to version 1.0 ? Dumping and restoring
>> from/to the same SVN version is not the issue.
That's kind of the point. If the repository changes db
schemas, or db backends, the dump/load format is invariant. It
exists to migrate from one version to another. We've already
had to make that transition a few times.
Well, how is that possible, really?
Sure, you can easily migrate across isomorphic (user invisible)
changes to the internal schema, but in the general case, how do you
migrate across user visible changes to the logical structure of a
repository?
Obviously within some subset range of logical structure changes you
can fill in default values and the like, but since the thread is about
early adoption: are you committing to not changing the logical
structure except in upward compatible ways, or are you saying that
revisions committed now are not promised to be "full citizens" after
future releases, or both?
Supposing that while adding some post-1.0 feature you discover that a
vast simplification or other fundamental change to the logical
structure is desirable (is that impossible? can you say with
certainty that it is unlikely given the post-1.0 features you're
considering?). Suppose that that logical structure change involves
recording information not captured by the 1.0 release. Doesn't that
mean that that history recorded by <= 1.0 releases is incompatible
with that of post 1.0 releases -- that any processes people have built
around the <= 1.0 data are threatened with obsolescence? (Or, if you
promise not to render their data obsolete wrt svn, that "advanced"
features may well be either precluded or certain to be implemented
awkwardly?)
Now if I understand the project priorities right, the answer is
something like "Our goal is to improve on CVS. Whether or not we do
that is orthogonal to the issues we raise." But now, at least for
long-lived projects, doesn't that answer point to a future where
revision control is either stalled at "slightly better than CVS" or
one characterized by "continuously shifting revision control
technology"?
Along these same lines, you've recently described 1.0 as a "stable
interface" -- a commitment of some sort. At the same time, there's
talk of post 1.0 consideration of features like changeset management,
history-sensitive merging, and distribution. What analysis of the
problem space gives you confidence that the interface can reasonably
remain stable as those advanced features are added? (I've seen some
quick and dirty suggestions for approaches to these features but
seemingly nothing sufficiently worked out that it justifies interface
commitments.)
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 1 03:43:43 2003