On Sun, 20 Nov 2005, Ben Collins-Sussman wrote:
> On 11/20/05, Jim Blandy <jimb@red-bean.com> wrote:
>
> > But this is a different case. No information would be lost. Or, more
> > accurately, the information that the file used to be an unknown ('?')
> > file in the WC would be lost, but I don't think anyone really cares
> > about that.
> >
> > What do folks think?
>
> 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?
>
I don't think efficiency as that important here. This shouldn't be a very
common case.
What about the following:
- Instal the textbase and properties as usual.
- If the working file exists, detranslate it according to the new
properties and compare to the new textbase.
- If they are the same, fine, else flag the file as conflicted.
(An alternative would be to just install the new text-base, which will
make svn treat the pre-existing file as a modified version of the new
file. But might this be too dangerous? It wouldn't loose data, but maybe
it is confusing.)
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 21 08:39:29 2005