Greg Hudson <ghudson@mit.edu> writes:
> So, I've been plowing into task #3, which requires me to understand
> the current state of libsvn_wc. Right now I'm confused by the update
> strategy. A comment in get_editor.c says:
>
> When we reach close_file() for file `blah', the following are
> true:
>
> - The new pristine text of blah, if any, is present in
> SVN/tmp/text-base/blah; and the file_baton is appropriately
> marked if so.
>
> And then later:
>
> 1. Discover and save local mods (right now, this means do a
> GNU diff -c on ./SVN/text-base/blah vs ./blah, and save
> the result somewhere).
>
> Isn't it a bit late to be discovering local mods if we've already
> updated ./SVN/text-base/blah? Perhaps apply_delta should create a new
> base file so that close_file has access to all three versions of the
> text (old pristine base, new pristine base, working copy) for a merge.
Don't worry -- the new text-base file is in tmp/text-base, not the
real text-base (read the first part carefully).
> Which brings me to the other issue I have: creating a temporary file
> to hold the new version of the pristine base. We have to do it one
> way or another, to apply the text delta if nothing else (right now we
> just nuke the pristine base file as we go, and the window handler can
> only handle "copy from new text"). We don't have any administrative
> naming scheme for these temporary files, APR doesn't have any logic
> for creating temporary filenames. Any bright ideas on this one?
??
No, we have a dedicated tmp area and a reproducible scheme for
generating names in it. The docs may not be complete enough, in which
case I sympathize with you, but this is exactly what the SVN/tmp/ area
is for -- look carefully at the behavior of svn_wc__open_adm_file()
and friends.
(This is how it is actually working right now, it's not just a
hypothetical plan).
Received on Sat Oct 21 14:36:09 2006