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

Re: (FS) operational question

From: Karl Fogel <kfogel_at_galois.collab.net>
Date: 2000-12-26 17:25:33 CET

I misguidedly wrote, in answer to Greg Stein:

> > Hunh. Has anybody pondered the issue that for a checkin *anywhere* in the
> > tree, that on the next "svn update", we have to hit *every* "entries" file
> > in the entire WC to update the revision number stored in there? It won't be
> > a matter of simply zooming past them doing nothing... we've got to rewrite
> > every single file.
>
> Nah -- you described the real solution below, actually. :-)
>
> > The alternative, of course, is to leave things at an old revision number
> > until a real change arrives, but then our state reporting grows
> > and grows as we get more exceptions throughout the tree (by
> > "exception" I mean a child needing to report a revision that is
> > different than the parent's).
>
> That's been the plan, yup...

Sorry, I was answering the wrong question.

In fact, on an update, yes, we probably will update everything to the
highest revision we possibly can. The cost of the local entries files
rewrites is outweighed by the reduced network traffic later, when we
have fewer exceptions to report in most directories.

Anyway, this seems reasonable to me... I mean, we did update those
things, so we should record the new up-to-date information somewhere,
right? The fact that recording it incurs some bookkeeping is only
natural.

In any case, if we don't update them, the price is simply that
state-reporting grows more expensive over time. I like
trade-offs... They feel like evidence that real work is being done,
and that someone has to pay for it. :-)

-K
Received on Sat Oct 21 14:36:18 2006

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.