kfogel@collab.net writes:
> "Perry E. Metzger" <perry@piermont.com> writes:
> > One possibility that comes to mind: just keep a log in the database
> > of property changes between two revision numbers. If you change a
> > property, it gets put in the log, and then the incremental dump
> > mechanism could just extract them along with the changes between those
> > revisions. It is a slight hack, but it would fix the problem of
> > incrementals not really fully containing the state changes of the
> > database.
>
> Heh -- yes, Ben Collins-Sussman and I were just talking about that,
> after reading one of your earlier mails.
>
> Could you file a 'feature' issue on this, and describe roughly how you
> think it would work? I can't say when we could schedule it for
> (mostly depends on which developer gets interested enough to actually
> do it -- of course, a patch will accelerate this process! :-) ). But
> having it in the tracker makes it more manipulatable ("manipulable"?).
>
> I think it's a good idea, though we probably haven't thought of all
> the implications yet...
Actually, I'm -1 on such an idea. The Subversion filesystem tracks
all the information it needs to track to work. It is not the job of
the filesystem to remember what portions of it the administrator deems
"safely backed up."
In my opinion, the right steps to make this work are:
- Fix the dump file format/dumper/loader to understand the notion
of a revision property patchup record. Right now, all revision
records indicate that a new revision needs to be created. It'd
be great to be able to say, "Just update the properties of this
already-existing revision."
- Give 'svnadmin dump' a flag which says, "Do a rev-property-patch
dump".
- Tell people to use this type of 'svnadmin dump' in their
post-revprop-change hooks.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Feb 19 19:19:50 2004