On Wed, 23 Jul 2003, Julian Fitzell wrote:

> Sure, though Daniel could also just send a generated changeset and you
> could apply that to your image and save a new version.  But whatever...
> there a few benefits to doing it your way.

Yes, like actually retaining the version history - if Daniel produced his
changes by merging in some other versions, we would want to record that,
or we'd be in trouble when we wanted to merge again later.
I really don't think it makes sense to "regress" back to changesets,
except for when backwards compatibility with, eg, the update stream is
needed.

> It does seem to me though, that the tendency would then be to always
> send around smaller patches rather than full versions.  And the more you
> do that, the less likely you are to have all the versions you need to
> actually recreate a full version.  Sounds a little like a slippery slope
> towards a central repository.

Well, that's a matter of policy.  I would tend towards something like:

- all stable releases are made available as full versions
- all intermediary versions are saved as patches *against the
preceding full release*, not against another intermediary version

That way as long as the stable releases are widely available, there
shouldn't be any problem.  I agree that if you got into the habit of
distributing patches of patches of patches of a full version, then the
system becomes much less robust.

However, as Daniel points out, if you just gzip the version, it's not that
much space anyway.  So this might all be premature optimization (which is
why I haven't implemented the feature yet...).