Re: Eric goes to lunch -- a decentralized-development user story

Benjamin Pflugmann <benjamin-svn-dev@pflugmann.de>:
> Back to your premise: a dump file is a list of history diffs. A
> repository is a dump file applied in order. But it's also more: it's a
> filesystem with constraints (you cannot delete any of the history
> diffs).
>
> So... not every storage of history diffs implies an order/sequence or
> means you cannot delete those diffs anymore. (Although history diffs
> started with an order in mind, you can easily exchange them as long as
> the exchange doesn't create a conflict).
>
> So yes, patch management is some kind of repository, but it's not a
> Subversion repository, except if you put some wrapper around it to
> handle its constraints.

Verry interresting. Yes, you've pointed out a real difference between a
patch queue and a repo.

I believe it is actually possible to zap revisions in a Subversion
repo. There's a note about it in the Subversion book. It's
discouraged, as I recall.

Nevertheless, I think you have a point here. But it leads to the next
question: would it be better to solve the problem local patch queues
address with local patch queues, or by adding a policy option to repos
that loosens the repudiability and ordering rules in an equivalent way,
and using a local repo?

I like shaving with Occam's Razor. You know, "Do not multiply entities
beyond necessity?" So I still have to lean towards the local-repo option.

I'm listening and my mind is open, however.

-- 
		Eric S. Raymond
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org