[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Benjamin Pflugmann <benjamin-svn-dev_at_pflugmann.de>
Date: 2004-09-17 04:14:01 CEST

On Thu 2004-09-16 at 21:49:20 -0400, Eric S. Raymond wrote:
> Benjamin Pflugmann <benjamin-svn-dev@pflugmann.de>:
> > > For example, how do I save log text with my local patches?
> >
> > Okay, I always referred to action diffs, but I see no reason not to
> > store a history diff instead. I already implied that one should name
> > the checkpoint, there is no reason not to ask for log message, too.
> Right. I pointed at something that your iteration 0 notion of a local
> managed patch set didn't handle. You said (in effect) "no problem,
> we'll make the local patches history diffs rather than action diffs."

Yes and no. You are right, that are my words, but something different
happened than you seem to imply.

I already considered for my iteration 0 proposal whether I want
history diffs and decided that I wouldn't want a log message attached
(my patches go through too much iterations, so that I always write the
log message only when I commit).

> Remember the first premise, that a dump file is just a history diff
> on the empty tree? A repo is nothing but a sequence of history diffs.
> The moment that you say your local objects are history diffs, *you've
> just reinvented the repo*!
> *FLUSH* gurglegurglegurgle
> And that was the sound of "local patch management" going down the
> crapper.

Not really. I carry around with me the idea of how to improve patch
management in Subversion for a long time already. And one of the
implementation ideas I have gone through is to "simply" drive the
existing WC editors with the equivalent of what the server would send
for an update. So using action or history diffs is nothing new to
me... I just didn't have a name for them until this thread began.

I explained in my other email why I don't think this is the equivalent
of a local Subversion repository.

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

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.

It's getting late (4am) and I cannot express myself well anymore (if I
ever could), so I'll let this rest for now and see if I can explain it
better when I am up again.



To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 17 04:14:24 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.