> > She replied, "Yeah, but my working copy is now lost, as it
> was replaced with
> > the merged version. So now I have to manually go through
> the file and try to
> > sort out my code from the other code. I think I'll make a
> backup of my
> > working copy before I update each time."
>
> Her changes are only "lost" if they were exactly the same as changes
> someone else made. 'svn diff' will still show the changes she made
> that weren't identically made as well by someone else.
Her lines of code were merged with what was in the repository. If she wants
to restore this file in her working copy to its state before the "svn up"
command was executed, she must manually go through the file, line-by-line,
and remove lines added by the merge process. The original file, premerged,
is lost (though all of the lines of code are preserved in the merged file,
they much be manually sorted out).
That's the issue this user has with subversion, and why she is making backup
copies of her working copy before doing "svn up".
After some thought, a --paranoid flag on "svn up" wouldn't have to produce a
conflict... all it would have to do is make a backup copy of the working
copy of any file that is merged. I think this solution would make her happy.
--- Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 18 17:02:53 2003