I suspect this is a problem on the nightly build server coming from the
switch to Sourceforge. I've made a change to the build script which should
hopefully bring it up to date again.
Kind regards,
Daniel
måndag 23 oktober 2023 kl. 11:43:12 UTC+2 skrev Tim C:
> The last line in Changelog.txt copied by the latest nightly build
> installer reads:
> "- NEW: Added a menu item in Project monitor to check one specific
> project. (Daniel Sahlberg)"
>
> So it seems that r29597 somehow did not make it to the nightly build, as
> it added another line to Changelog.txt after the one I have quoted.
>
> On Sunday, 22 October 2023 at 18:57:45 UTC+10 Tim C wrote:
>
>> Hi Daniel,
>>
>> I have just installed the most recent nightly build, but cannot see the
>> MergeAllowMixedRevisionsDefault setting. Please see screenshots. What am I
>> doing wrong?
>>
>> [image: s1.png][image: s2.png]
>>
>> Thanks,
>> Tim
>>
>> On Monday, 31 July 2023 at 06:59:44 UTC+10 Daniel Sahlberg wrote:
>>
>>> torsdag 20 juli 2023 kl. 03:11:10 UTC+2 skrev Tim C:
>>>
>>> > Would it be possible to add an "Update" button to the merge failed
>>> dialog that starts an update and reopens the merge dialog with selected
>>> revisions again?
>>>
>>> +1, this would be very helpful
>>>
>>>
>>> There is already code to take care of this, see attachment. However it
>>> relies on the exact error returned from the Subversion library ("Cannot
>>> merge into mixed-revision working copy", or rather the specific error
>>> number 195020 used internally).
>>>
>>> If there is a case where the merge produce an error but the Update
>>> needed dialog isn't show, please report how to reproduce it (preferably
>>> with a screenshot or copy of the error message) and we can probably catch
>>> that as well.
>>>
>>> Also is it possible to set the default value of the 'Allow mixed
>>> revisions' checkbox in the Merge options dialog? In my use cases (cherry
>>> pick merges of several commits one after another) it is an extra step that
>>> I always forget to do and have
>>>
>>> to re-initiate merge (pick up the source branch again, re-select
>>> revisions etc.). It is time consuming and very annoying when it fails. An
>>> internal config variable (under Advanced page in Settings) would be
>>> sufficient.
>>>
>>>
>>> I have added such an option in r29597, there will be a new advanced
>>> setting MergeAllowMixedRevisionsDefault controlling the default state of
>>> the "Allow mixed revisions (not recommended)" checkbox. Because of problems
>>> with the nightly builds, you currently need to build TSVN yourself if you
>>> want to test it.
>>>
>>> I will one last time repeat what is written in the Subversion book about
>>> mixed-revision working copy merges:
>>>
>>> [[[
>>> Without going into too much detail, this is because of limitations in
>>> the way merges are tracked by the svn:mergeinfo property (see the section
>>> called “Mergeinfo and Previews” for details). These limitations mean that
>>> merges into mixed-revision working copies can result in unexpected text and
>>> tree conflicts.[34] We don't want any needless conflicts, so we update the
>>> working copy and then reattempt the merge.
>>> ]]]
>>>
>>> Also re-posting the link provided by Stefan previously about one example
>>> of how to hit the described error:
>>> https://groups.google.com/g/tortoisesvn/c/cplTU-e_IU0/m/aW6M6kTmAwAJ
>>>
>>> Anyhow, if your workflow works doing mixed-revision working copy merges,
>>> then feel free to set the new advanced setting.
>>>
>>> Kind regards,
>>> Daniel Sahlberg
>>>
>>>
--
You received this message because you are subscribed to the Google Groups
"TortoiseSVN" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/tortoisesvn/f5e8ee39-8d53-4bf3-b18b-e758d67fe1e2n%40googlegroups.com.