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.
> The server then says, "OK, I have nothing to send
> you, then." Of course, the working copy and repository completely
> disagree on what "version N of foo.c" means, but they're not aware of
> that. You'll never get the diff from the server, and thus never get a
> copy of what's really in the repository.
>
> It's even worse than that: when you change foo.c again and try to
> commit, your client is going to send binary diffs to the server (again,
> by comparing the working file with the cached .svn copy). The server is
> then going to try and apply these binary diffs to a file that has
> DIFFERENT CONTENT.
>From my lurking on subversion lists, I thought that scv commit etc. sent
a checksum of the base as well as a diff to prevent this sort of
situation. Have I misunderstood?
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Feb 12 01:10:21 2004