On Fri, 2003-12-19 at 11:06, Wadsworth, Eric (Contractor) wrote:
> > > Isn't there a small gotcha here? If parts of his local
> > changes matched
> > > the changes from the new version, then wouldn't those be lost?
> >
> > That's true, yes!
>
> Damn.
>
> So, are we classifying loss of code as a "small gotcha" now?
>
The code isn't 'lost'. The non-unique changes been committed already.
It's a permanent part of a repository.
The inconvenience here is that there's no way to get back the *exact*
working file before the update happened. The unique local mods continue
to exist no matter how much you backdate or update the file. The
nonunique local mods exist in HEAD in the repository, and can be viewed
by examining 'svn diff -r HEAD-1:HEAD'. There's no loss of changes,
just a small risk of fragmenting them.
> My developers have requested that they be able to undo a harmful merge.
I think your developers are being paranoid; in practice, this scenario
almost never happens, and when it does, it almost never matters. The
benefits of merging nonunique changes *far* outweighs the minute risk of
inconvenience that I've outlined above.
If your developers are somehow working different than the rest of the
world, and this scenario *does* become a real problem, then I'd like to
hear about it. For now, they can be extra paranoid and run 'svn diff >
patchfile' to backup local mods before running 'svn up'. Or they can
just hand-copy the working file to /tmp beforehand. But again: this
sounds to me more like the incorrect prediction of a problem, rather
than complaints based on real problems.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 19 18:25:29 2003