Subversion 1.5 already (partially) solves this problem. It's using
infrastructure that has been in subversion client/server since day 1,
but was never taken advantage of until recently.
Specifically, when the server transmits an 'update' to the client, it
sends (1) a delete command and (2) a copy command. What's new in svn
1.5 is that the copy command now includes the "copy source" path. The
client attempts to find the copy source in the working copy (as a
pre-existing versioned file), rather than the server blindly pushing
the file at the client. This means, in your example, the client would
copy the locally-modified foo.c to bar.c rather than receiving an
older version of bar.c.
That's the ideal scenario, of course. The snag in this system is that
there's no way to prevent the server from doing the 'delete' before
the 'copy'; if this happens, then the client can't find the
locally-modified file to copy. The plan is to fix this problem in svn
1.6, by having the client track deletions during an update (perhaps
not really doing the deletions until the very end of the update, thus
making sure they're available for the copy.)
For more info on this, see issue 503 in the bugtracker. It would be
great if you wanted to help out.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 16 13:43:44 2007