On 25.07.2016 12:09, George Stein wrote:
>>> On Wed, Jan 29, 2014 at 9:14 PM, Stefan Küng <tortoisesvn at gmail dot com> wrote:
>>>
>>>> On 29.01.2014 13:57, Baruch Burstein wrote:
>>>>> I found a bug in the restore after commit feature.
>>>>> Consider the following scenario:
>>>>>
>>>>> I have a file 'foo.c' that I want to commit only part of.
>>>>> I mark it for restoration after commit, which saves a copy of it aside,
>>>>> and then edit it
>>>>> I try to commit, but get an error that some of the files in my commit
>>>>> are outdated, including 'foo.c', and a dialog to select update working
>>>>> copy or cancel (I don't remember the exact messages)
>>>>> I click 'Update', and tortoisesvn updates my working copy, including
>>>>> `foo.c`, merging it *with my temporary version*
>>>>> I get the commit dialog back, and perform the commit
>>>>> HERE IS THE PROBLEM: After the commit, 'foo.c' is restored from it's
>>>>> copy that was put aside, which is it's old version before the update. I
>>>>> am now left with an updated working copy, but an old 'foo.c'
>>>>
>>>> Now show the diff of that file against BASE, and you can revert the
>>>> changes that got updated.
>>>>
>>>
>>> I know it can be worked around. The problem is that it is not at all
>>> apparent that there is anything wrong. I did an update and a commit, and I
>>> thought I was now at the latest version. When I tried compiling I suddenly
>>> got errors. I might of even compiled fine and gotten runtime errors and
>>> never would of guessed what the problem was.
>>>
>>> Also, I spent a few minutes doing the merge with the update, not realizing
>>> I was merging into my edited file. This causes a pointless and annoying
>>> merge.
>>>
>>> --
>>> ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
>>
>> I agree with Baruch. In my opinion it can not be expected that the developer must be make a diff against BASE.
>> Is it possible to merge the file content from the "patch" commit and the local changes?
>
> I also came across the problem and thought it is fixed in the latest versions, but it isn't.
it isn't fixed because it's not a bug.
> The workaround is possible of course but not obvious to less experienced users.
>
> Is there a chance to implement a behavior described by the other posters?
No, here's why:
after an update, you *have* to check your version again before you do a
commit. You can not know whether the updated changes interfere somehow
with your own changes. So you have to check.
Really: if you don't check, you risk committing something that doesn't
work. Whether you have used the "restore after commit" feature or not.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest interface to (Sub)version control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3180111
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2016-07-25 19:40:01 CEST