Sean Russell <ser@germane-software.com> writes:
> BTW, Zack mentioned that:
>
> > As a side note, on IRC ben asked people to wait on this project until
> > next week because he has massive outstanding changes in get_editor.c
> > (to implement svn switch on a single file).
>
> I'm going to go ahead, because I don't see that what Ben's doing is going to
> affect what I'm working on in a way that will make me have to start all over
> again. The only two things that could happen (that I can see) that will
> affect my sub-project is (1) somebody else solves the issue some other way,
> or (2) the nature of the diffs change. Since I'm going to be using patch and
> diff3 instead of parsing the files myself, I don't think (2) would affect me
> much, and if (1) happens... well, c'est la vie.
My change is done.
Essentially, the update-editor's close_file() is now a public function
called svn_wc_install_file() -- read the docstring in svn_wc.h.
This function is *the* function that does the textual merging, and is
the one you'd be hacking on.
Here's our current algorithm for accepting new text during an update,
more or less:
assume new-text-base exists (constructed from binary diffs)
create a stringbuf "log"
write logbuf: mv new-text-base text-base
if (working file isn't locally modified)
write logbuf: cp text-base working-file
else /* locally modified */
if (file is textual)
`diff text-base new-textbase > patchfile`
reserve unique .rej filename
write logbuf: patch working-file -r .rej < patchfile
else /* file is binary */
reserve unique .orig filename
write logbuf: cp working-file working-file.XXX.orig
write logbuf: cp text-base working-file
write logbuf: bump revision, timestamp, possibly url
flush logbuf to disk
run log
Of course, this is a *gross* simplification, as this function does all
sorts of property merges and eol/keyword translation too. But now you
get the general idea. Whatever this list decides on, and whomever
ends up hacking on our merging process, this is the backdrop. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:06 2006