You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Bob Gustafson <bo...@rcnChicago.com> on 2003/01/01 01:25:01 UTC
Re: svn 1.0 in 2006 or now?
Garrett Rooney wrote on Tue, 31 Dec 2002 15:52:44 -0500:
>On Tuesday, December 31, 2002, at 03:50 PM, Bob Gustafson wrote:
>
>> Maybe having a process (or a guarantee that a process would exist) to
>> roll
>> out a repository to storage in a suitable form and then roll it into a
>> future updated (modified API/Code/Etc) repository would be enough for
>> folks
>> to use SVN for more projects, even in its present form.
>
>uh, we have that. svnadmin dump/restore. it's been working for months.
>
>-garrett
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.
BobG
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by Bob Gustafson <bo...@rcnChicago.com>.
David Summers wrote on Wed, 1 Jan 2003 01:58:07 -0600
>On Wed, 1 Jan 2003, Bob Gustafson wrote:
>
>> 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.
>
>Well, last weekend I got a preliminary "svnadmin --xml dump" both as C
>code changes to svnadmin and then as a perl script that eats the normal
>"svnadmin dump" output and spits out XML. :-) People said there was no
>use-case for it. Is this a possible use-case for it? I've not yet done
>the "svnadmin load".
>
Close, but... I think that the xml tags need to be 'in' the repository
rather than attached to fields as part of an output process. The idea is to
have old version data (ignored perhaps) and new version data side by side
within the repository. As the repository grows, those old fossilized bits
of data will remain (nothing drops to the floor), but they may become
increasingly difficult to get at.
An administrator (or paid outside consultant :-) may set up an audit -
usage counting or something on that old data. If it is not being used, then
perhaps a willful whack can be done. But, this set of decisions would be
done at the user level and the timing etc., would be completely independent
of the svn development decision stream.
Think of human DNA. There are lots of bits of unused data hanging around -
probably for millions of years. Things still work. (now if we could only
read those old 'tags'..)
BobG
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by David Summers <da...@summersoft.fay.ar.us>.
On Wed, 1 Jan 2003, Bob Gustafson wrote:
> 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.
Well, last weekend I got a preliminary "svnadmin --xml dump" both as C
code changes to svnadmin and then as a perl script that eats the normal
"svnadmin dump" output and spits out XML. :-) People said there was no
use-case for it. Is this a possible use-case for it? I've not yet done
the "svnadmin load".
--
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david@summersoft.fay.ar.us PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
PGP Key fingerprint = C0 E0 4F 50 DD A9 B6 2B 60 A1 31 7E D2 28 6D A8
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by Bob Gustafson <bo...@rcnChicago.com>.
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
Re: svn 1.0 in 2006 or now?
Posted by Tom Lord <lo...@regexps.com>.
It's not because it's New Year's Eve [Happy New Year btw !]
that people will be drunk enough to accept that suddenly ;)
I suppose you may be right that that was my highest hope. (And Happy
New Year (and cheers) to you et al. also.)
More seriously: I've 99.9% given up on convincing the core developers
to reconsider their design but the question and answer did (and does)
seem like a fairly unique opportunity to try to draw out some of the
implications of their decision for that .1% shot; a fairly vivid
abstraction->instance situation.
But changing the whole subversion design (which you are
trying to say implicitly, ain't you ? :) ) is just madness.
In my eyes, it would be honorable bravery and a superlatively good
engineering decision.
Assuming it does require such drastic design changes, why not
make it 2.0 and just have some scripts to transfer 1.0
repositories to 2.0 format ?
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).
If it doesn't last forever, it doesn't mean it cannot be used
before something better is done.
You have to look at the costs of deployment, not just the "small
matter of hacking". This is a damn conservative area and rightfully
so.
5...4...3...2...
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by Tom Lord <lo...@regexps.com>.
You might very well be able to add to that list of design concerns,
but I doubt you'll uncover anything that, at this point in history,
justifies at least planning in detail for those features and
incorporating that planning into any widely deployed release.
"_not_ at least planning", of course.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by Tom Lord <lo...@regexps.com>.
> 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
Whatever the change, I suppose there will still be some kind of
isomorphic relationship between both formats, because there
will still be log messages, revision numbers, etc. Therefore,
it's just a matter of writing a tool capable of converting one
format into the other.
If the new format contains more info than the previous one,
those new fields will most likely stay blank if they cannot be
generated from the previous format.
Just as a "minor" point, you are engineering by faith only:
I _suppose_ there will [...] be [...] some kind of
isomrphic relationship [because of just a few underspecified
factors common to all formats]
[....]
If the new format contains more info [...] new fields will
_most likely_ remain blank [and, implicitly, this will not
impact users]
It seems to me that the sum of concerns of arch and svn (pre and post
1.0) cover roughly:
*) A CVS-like user interface
*) changeset management
*) distribution
*) process integration
*) long-lived archives
and that _none_of_those_topics_are_mysteries_. There's no good reason
to just "suppose" or wave topics away with "most likely".
You might very well be able to add to that list of design concerns,
but I doubt you'll uncover anything that, at this point in history,
justifies at least planning in detail for those features and
incorporating that planning into any widely deployed release.
I think I'll shut up now unless someone replies with something really
interesting.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by Sebastien Cevey <se...@cine7.net>.
On Tue, Dec 31, 2002 at 06:50:34PM -0800, Tom Lord wrote:
> 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
Whatever the change, I suppose there will still be some kind of
isomorphic relationship between both formats, because there will still
be log messages, revision numbers, etc. Therefore, it's just a matter
of writing a tool capable of converting one format into the other.
If the new format contains more info than the previous one, those new
fields will most likely stay blank if they cannot be generated from
the previous format.
> 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?
Indeed. But changing the whole subversion design (which you are
trying to say implicitly, ain't you ? :) ) is just madness. It has
been talked over and over on this list. It's not because it's New
Year's Eve [Happy New Year btw !] that people will be drunk enough to
accept that suddenly ;)
Assuming it does require such drastic design changes, why not make it
2.0 and just have some scripts to transfer 1.0 repositories to 2.0
format ? Current SVN is so close to be mature that it'd be completely
stupid to stop here and rethink the whole thing. If it doesn't last
forever, it doesn't mean it cannot be used before something better is
done.
I mean, CVS -> SVN can be done, and I think there exists such tools
for almost all SCM. So why couldn't it be done here ?
--
Sebastien Cevey <se...@cine7.net>
Cine7.Net - Milcis.Net
Jabber: theefer@charente.de - ICQ: 48895760
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.0 in 2006 or now?
Posted by Tom Lord <lo...@regexps.com>.
>> 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
Re: svn 1.0 in 2006 or now?
Posted by Ben Collins-Sussman <su...@collab.net>.
Bob Gustafson <bo...@rcnChicago.com> writes:
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org