[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: Eric S. Raymond <esr_at_thyrsus.com>
Date: 2004-09-17 03:49:20 CEST

Benjamin Pflugmann <benjamin-svn-dev@pflugmann.de>:
> > I know immediately I'm going to run up against those limits.
>
> Really? How? Wanting to know more about that was what made me write my
> email to begin with. I don't mean to say you wouldn't run against
> those limits. It's just that I don't recall anybody, who asked for a
> local repository, present a use case in the Subversion context that
> wouldn't be solved by such a "patch management". (and I mean a real
> use case, something one already stumbled upon, not a theoretical one).
>
> > 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."

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.

> Although I have no concrete reason against the idea of automatic
> branch creation in this context, the idea that after week-ends or
> similar events, the repository sees a lot of automatic branches which
> will live only for some minutes (until they are no longer needed),
> scares me a bit.

Reasonable. I'm not entirely happy with it myself and am trying to
come up with a better way.

-- 
		Eric S. Raymond
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 17 03:50:50 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.