On 5-Feb-06, at 5:34 AM, John Allen wrote:
> On Friday 03 February 2006 17:05, Scott Palmer wrote:
>> On 2-Feb-06, at 6:53 PM, Ryan Schmidt wrote:
>>> On Feb 3, 2006, at 00:33, Scott Palmer wrote:
>>>>>> But what happens, if the svn update can merge the file without a
>>>>>> conflict? Then I do not get the .mine and the two .rXX files. SVN
>>>>>> changed my work, and i can not go back to the file I had. Is
>>>>>> this right?
>>>>> NO. svn revert, that is as long as you have not done an svn
>>>> svn revert will undo local changes.. it won't undo the merged
>>>> changes from the update because they now match the base revision.
>>>> To go back you would have to know what the previous base revision
>>>> was and reverse merge the changes from the update.
>>> If you merge, and have not committed yet, then you can svn revert
>>> those changes. Once the merge command is done, the edits look no
>>> different to Subversion than if you had made them by hand.
>> Re-read the top line that I quoted. In this case the "merge" is a
>> result of an "update" action. The *update* will change the base
>> revision of the files so the only "changes" that can be reverted are
>> your own.
> I re-read the original original post; I don't know what client this
> guy was
> using, but here is what I basically think he did.
> 1. commit (failed, need update)
> 2. update (created conflict)
> 3. Selected relevant option in whatever GUI tool he was using to
> replace his
> file with latest from repository.
> 4. *screwed*
> Sunversion does not do this. When he had a conflict, he should have
> a .mine file, so he must have chosen an option in his GUI tool to
> dump his
Right. But I was responding to the questions I quoted. In that
scenario an update that pulls in changes *without a conflict* can not
be 'undone' by 'svn revert'. That's all I'm trying to clarify.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Feb 6 16:58:02 2006