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". 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. Most likely, the binary diff application will
completely fail. And if it doesn't, you'll have a totally corrupted,
mangled repository file.
So I'm not being paternalistic here: there is *no* way to do what you
want with Subversion. All roads lead to data corruption. The only
possible solution I can imagine is that every employee destroy their
working copy after *every* commit they do, and checkout a new one.
---------------------------------------------------------------------
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:01:45 2004