On Mon, Mar 05, 2007 at 02:50:46PM -0800, Karl Fogel wrote:
> > I understand. I guess that means that bumping the db/format file needs
> > to be an offline operation then, so we can guarantee that old readers
> > have stopped reading.
>
> Remember that it's okay to have multiple representations of the same
> historical data present at the same time -- readers don't care which
> source is behind the data they're getting...
>
Sure, although we can't move the data into the right place until we can
be sure that old readers have finished reading, which would be the
simple way to do it. I'd rather not have to copy each revision to the
new place just because someone did a read (especially since I'd be
racing with other clients doing the same thing).
> > So lets say we do implement this transparent upgrade path - how does the
> > repository admin mark the repo as 'safe to upgrade'? Should we just say
> > "manually take the repo offline and run this tool (which does 'echo N >
> > db/format')"?
>
> ...so upgrading the format can happen whenever you're ready to make
> new connections from older clients return errors. And then *after*
> the repository format has been upgraded, the old representations can
> be cleaned out.
We still have a theoretically infinite window between the time that the
the db/format file is bumped and the last reader stops reading. In
practice, it might not matter: there's not a great deal of difference
for a reader between 'format is too high' and 'rev file disappeared'.
Regards,
Malcolm
- application/pgp-signature attachment: stored
Received on Tue Mar 6 00:18:51 2007