On Mar 12, 2004, at 10:27 AM, Ben Collins-Sussman wrote:
> On Fri, 2004-03-12 at 10:17, Travis P wrote:
>> Couldn't svn be using /tmp for temporary files on systems that support
>> such a thing?
> Hm, I suppose that could work. But it kind of destroys the "wc is self
> contained" philosophy. The WC journals all of its actions, then
> executes the journal. Our philosophy has always been that the
> journal-commands refer to things strictly within the working copy.
> Suppose you interrupt a WC operation, so that your WC is locked with
> journals lying around. Then you let your WC sit around overnight.
> During the night, a cron job cleans out /tmp. The next morning you run
> 'svn cleanup', which attempts to finish running the WC's journals...
> the journal refers to copying/moving a file in /tmp that is no longer
> there. Whoops.
Interesting details. Yes, it sounds like a non-trivial project to
the speed advantages of /tmp: WC journals would have to have
a flag and intelligent handling of such files that might disappear
one client invocation and the next.
For this particular discussion where this came up, it's a non-issue
because of the 'mv' so the time spend on the copy to .svn/tmp is work
that had to
be done anyway but maybe there are other situations when using /tmp
.svn/tmp could provide significant performance improvements?
I don't have time for a thorough investigation and patch development
at this time myself, so I'll just leave it at that.
>> On the other hand, given the statements about (4), maybe that
>> temp file could be moved/renamed to become the text-base file rather
>> than yet another copy. Maybe this is already done efficiently and I'm
>> just unaware of that and misreading this conversation.
> Oops, yeah, actually, I forgot about that detail. We *do* do a 'mv'
> from .svn/tmp/ to .svn/text-base.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Mar 12 19:21:13 2004