On Thu 2004-09-16 at 22:52:07 -0400, Eric S. Raymond wrote:
> 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.
The possibility is to dump your repository, edit it (maybe by tools),
and create a new repository from it.
> 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?
As I (tried to) say in my other email: either way is fine with me (not
that I matter much). I care more about the ease of the UI than the
implementation. I brought up implementation issues only because I
thought avoiding repos syncs maybe would be the easier way to get a
solution to the use cases.
> 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.
Well, having had some days to let sink it in, I think the local-repo
option has a more realistic chance to become implemented, as any
change to libsvn_wc (and my suggestion would need those), will have a
hard time to be accepted.
> I'm listening and my mind is open, however.
Well, since both our ideas would benefit from a specification of
history diffs, we could take a step back and start with creating some
fundament.
Bye,
Benjamin.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 22 02:54:30 2004