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

Re: Pre-commit transaction modification question

From: Brett Wooldridge <brettw_at_riseup.com>
Date: 2004-02-12 02:48:54 CET

Simon Kitching wrote:

>On Thu, 2004-02-12 at 12:57, Ben Collins-Sussman wrote:
>>On Wed, 2004-02-11 at 17:48, Brett Wooldridge wrote:
>>>CVS has the same 'issue', in that after checking in the source, the
>>>source in the repository nolonger matches the source on the user's
>>>system [...] the only side-effect being that an immediate diff will
>>>show the differences in formatting, but after an 'update', the work is
>>>right again.
>>That won't work in Subversion. Honest. 'svn diff' is not a network
>>operation: it compares the working file with the cached copy in .svn/.
>>It's worse than that: when you run 'svn up', the client says: "I have
>>version N of foo.c".
>Just in theory, the client could say "I have version N of foo.c, with
>checksum xxxxx". The server is then able to detect this and return a
>corrected file. The .svn/Entries file already holds a checksum for each
>base file, doesn't it?
>Not that I'm asking for a new feature - just pondering.
I have to agree with you. The checksum (or MD5 hash) method was going
to be my
suggested solution. Additionally, it seems like running a 'diff' off of
a local cached copy
is possibly frought with issues of it's own. What if the file has
changed dramatically on
the server through another commit? My diff isn't going to show that?

Anyway, regardless of the diff issue, it seems like update could
certainly send an MD5 hash
along with the version. In fact, I'll be glad to implement it, if it
would be welcome.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Feb 12 02:49:10 2004

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.