Tom Lord wrote on 31 Dec 2002 20:19:26 -0800
>Because for non-trivial deployment, you should consider the logical
>structure of your repository an at _least_ a 10 year investment, and
>probably a few multiples of that. Screwing around with it every few
>years and propogating that screwing around through your development
>and support process is kind of wacky. I think it's not too different
>from library cataloging systems: you don't see too many major
>overhauls to dewey or library of congress classifications every 2.5
>years, for example (may be a U.S.-centric analogy - sorry).
>
How about relaxing the requirement of dump/restore across versions to a
limited delta between versions?. It 'should' be possible to dump/restore
between version 0.93 and 0.94 for example.
If the 'should' was changed to 'guaranteed', then folks could breath a bit
easier - with the knowledge that *at most*, they would only have to
dump/restore N times to bridge the gap between version 0.94 and 0.94 + N,
if they fell behind the bleeding edge for awhile.
If this guarantee was part of the development committment of svn, then
there would be no worry that svn would have to support some fossilized
design many (internet) years into the future. There would always be an
automated process (perhaps multistep) that could be applied to an old
repository to bring it up to the current design.
-------
Some thoughts
If the 'fields' of svn were fixed at each development stage, then if fields
were added, the content of those new fields would be blank for old
versioned data. If 'fields' of svn were deleted in going to a new version,
then data would drop on the floor during the repository upgrade process -
maybe not such a good idea.
If the fields were labeled (xml tagged) within the repository, then old
fields still could exist (but be ignored by current processes) in newer
repositories. The current data structures may change, but no data would
drop on the floor. To access old data however, would require some special
purpose parse code, or perhaps as an alternative to writing code, the
dump/restore processes could be done in reverse on those repositories.
Happy New Year (CST)
BobG
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 1 08:29:03 2003