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

libsvn_wc update strategy

From: Greg Hudson <ghudson_at_mit.edu>
Date: 2000-09-28 13:57:15 CEST

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.

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?
Received on Sat Oct 21 14:36:09 2006

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