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

Re: Overwriting WC files with 'update'

From: <kfogel_at_collab.net>
Date: 2005-11-21 04:07:42 CET

Ben Collins-Sussman <sussman@red-bean.com> writes:
> At the moment, I think the update-editor notices an existing filename
> which conflicts, and bails out early before receiving the svndiff data
> from the server. We'd need to change that behavior, and allow the
> editor to construct the repository file within .svn/tmp/, as it
> usually does. Then, before moving '.svn/tmp/foo' to 'foo', it would
> need to see if the two files have identical content or not.
>
> That's tricky: what's the most efficient way to do that? Begin by
> comparing file sizes, then resort to brute-force byte-by-byte
> comparison? (We have functions that already do that for detecting
> local mods in a working copy). Or maybe we should do checksum
> comparisons instead?

Just to add to the trickiness:

Remember that the text-base file and working file may be different, if
there's keyword expansion or end-of-line translation going on. So it
sometimes won't be enough to reconstruct the repository file, we'll
occasionally have to reconstruct the working file too (in a tmp area)
and compare it to the existing working file.

For the same reason, checksum comparison often won't work, even if we
already have one of the checksums "for free".

+1 on the enhancement, of course. It's the Way Things Should Work :-).
I thought we'd had an issue filed for it, but I can't find it now;
#1554 is the closest, but it's only tangentially related.

-Karl

-- 
www.collab.net  <>  CollabNet  |  Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 21 05:28:43 2005

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.