[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: "Apply Patch" doesn

From: Bruce <bjc_tsvn_at_btinternet.com>
Date: Sun, 23 Jul 2017 11:29:20 +0100

Hi,

On 23/07/17 00:15, Pascal Av wrote:
>> On 15.05.2013 19:14, Ben Fritz wrote:
>>> On Tue, May 14, 2013 at 1:29 PM, Stefan Küng <tortoisesvn at gmail dot com> wrote:
>>>>> Here it is visually in case my description isn't clear:
>>>>>
>>>>> trunk_checkout
>>>>> ↳subdir_1
>>>>> |↳file_1
>>>>> |↳sub_sub_dir
>>>>> | ↳file_2
>>>>> ↳subdir_2
>>>>>
>>>>> Files file_1 and file_2 are modified. If I right-click on trunk_checkout
>>>>> or subdir_1 and choose "check for modifications", then select and
>>>>> right-click on the modified files within this dialog to create the patch,
>>>>> I get a patchfile with file paths "file_1" and "sub_sub_dir/file_2". This
>>>>> patch only applies with the command-line tool.
>>>> Tried this, and I can apply such a patch with TMerge without any
>>>> problems. Even though the patchfile only contains the paths "file_1" and
>>>> "subsubdir/file_2".
>>>>
>>>>> If I instead right-click on trunk_checkout and choose "Create Patch"
>>>>> rather than "check for modifications", the paths in the patch file are
>>>>> "subdir_1/file1" and "subdir_1/sub_sub_dir/file_2" and the patch can apply
>>>>> successfully with TortoiseSVN.
>>>> I've used a test working copy for this, using names "subdir1",
>>>> "subdir2", "subsubdir1", "file1" and "file2".
>>>>
>>>> If you're sure that TMerge finds the correct path (hover the mouse
>>>> pointer over the files in the patch file list in TMerge to see the full
>>>> path), then maybe your paths have special chars in them? Or something
>>>> else is different?
>>>>
>>> TMerge didn't have any file list, it came up empty.
>>>
>>> Rather than figuring out what's missing from my repository
>>> description, I created a simple test repository.
>>>
>>> Examine the attached file then rename it to a .bat extension. Running
>>> it will set up a repository and working copy which demonstrates the
>>> problem.
>>>
>>> After the script runs you should have an explorer window in the br1
>>> branch. Do "check for modifications" and create a patch from both
>>> files.
>>>
>>> On applying this patch in the "br2" branch, the TMerge window comes up
>>> blank, with no file list.
>>>
>>> Go back to the br1 branch, and this time do "create patch" from the
>>> top-level TSVN menu. Copy this patch to the "br2" branch and apply.
>>> File list is populated and I can "patch all items" to apply the patch
>>> with no problems.
>> Tried this with a nightly build from trunk (soon to be 1.8) and it works
>> fine there. Haven't tested with 1.7.x though, but 1.8 will be out soon
>> (1.8 RC2 for svn is currently awaiting the final signatures).
>>
>> Stefan
>>
>> --
>> ___
>> oo // \\ "De Chelonian Mobile"
>> (_,\/ \_/ \ TortoiseSVN
>> \ \_/_\_/> The coolest interface to (Sub)version control
>> /_/ \_\ http://tortoisesvn.net
> Hello,
>
> I met that behavior after upgrading an old client from Tortoise SVN 1.6.x to 1.9.x: the "Tortoise Merge" patch-files-list auxiliary-window was in fact out of the screen view port.
>
> Someone else hit the same issue, in a different context most probably: https://stackoverflow.com/a/44529286/2871702 .
>
> After de-maximizing the main "Tortoise Merge" window, I could see a bit of that aux-window borders on the left of the screen, so I could click-grab it and get it back into the screen viewport.
>
> I'm unsure what caused that behavior, which is still really misleading (it just visually appears as if Tortoise Merge was silently aborting the job upon opening the patch-file).
>
> That may be due to - from the most to the least likely situation -, either:
> - The enduser moved the auxiliary window on the side of its screen, in order to gain a better readibility of the main-window contents (i.e. the side-by-side diff)
> - The enduser screen resolution changed
> - The enduser killed a Tortoise related-process, leaving Tortoise Merge in a somehow broken state
>
> Anywhow, Tortoise may help to prevent this, by forcing the auxiliary-window to fully render inside the screen viewport?
>
> See you, Pascal
>
> ------------------------------------------------------
> http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3270926
>
> To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
It seems like this might be related to a query I raised on the mailing
list as "TortoiseMerge - File Patches tool window positioned on desktop
but off screen". It might be worth a look. As the thread states, I
believe that that issue was addressed as r27421.

Regards,
Bruce

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3271140

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2017-07-23 12:29:32 CEST

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.