I wasn't aware of the process implications you guys are discussing. I
un-request it ;-)

I'm still wrapping my head around the no-repository idea. Ok, lets try
something out -

Thinking about the same process issues, how about allowing a package
file to optionally include a publically accessible "release url". This
would declare the version a publically available reference point, so
patches against it would be reasonable. Of course it doesn't imply
"stable releases"ness, but stable releases could boast official urls.

This
* doesn't centralize the repository, but 
* uses the global url namespace to permit resolution of references to
specific versions
* allows patches without breaking the model, if that optimization turns
out valuable.

Daniel

Avi Bryant <avi at beta4.com> wrote:
> 
> 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...).