I get this every time I commit without the update prompt, and have to manually update then try again. Is this to do with the folder having merges from other tags to it stored? (noticed in diffs)
Thing is even if I had a prompt for it to update I'd still find it a problem as it still takes me over twice as long to do my merges now than before with how long updates take (they're quite large). Asking again if we could please have a setting to disable this check as it didn't seem needed before this, or maybe we just never encountered what it's meant to fix? Thanks, Kieren On Sunday, April 11, 2021 at 11:05:48 PM UTC+12 [email protected] wrote: > onsdag 7 april 2021 kl. 01:21:30 UTC+2 skrev Steve Wicinski: > >> Under v1.4.0 and before, Tortoise would normally merge with no issues >> multiple times (as stated above). If there were issues with the files, >> you'd get a dialog if you want to update, and if you said yes, it would >> update and then take you back to the commit screen to try the commit again. >> (This mirrors what you say). >> >> However, with v1.4.1, there are two changes. One is that it tells you far >> more often that your 'out of date' even though you updated prior to the >> last commit (there should be no reason that I'm out of date). Far worse, >> though, is the fact Tortoise no longer (or at least very rarely, I had it >> work once out of some 20 or more tries) prompts you to update after telling >> you an update is needed. It tells you an update is needed, then just >> closes. This is what is aggravating. You (a) have to now manually update >> when before tortoise handled it for you), and (b) you now have to start up >> the merge process again, requiring you to make the selections again, hoping >> you get them the same. >> > > Can you provide some steps to reproduce when TSVN tells you that an update > is needed but then doesn't prompt to update? I think that is definately a > bug. (I'm just saying that I have not run into it when testing this thread > or IRL but I must admit that merging is seldom part of my workflow). If it > can be demontrated with a reproduction reciept then someone can surely fix > it. > > Kind regards, > Daniel Sahlberg > > > > > >> On Friday, March 12, 2021 at 5:50:27 AM UTC-5 [email protected] >> wrote: >> >>> fredag 12 mars 2021 kl. 11:31:30 UTC+1 skrev DutchPavlo: >>> >>>> It is very nerving. We oft merging a lot of revisions at one time from >>>> development to our quality trunk. The merges have to been done seperate to >>>> insure the possibility too take them back or merge them too trunks of >>>> clients. After each merge you have too update the repository. Why is this >>>> not done by the merge? >>> >>> >>> This was a design decision by the Subversion project (back in 2000-2001 >>> when Subversion was created) that you can have "mixed revison working >>> copies". Some background can be found in the SVN book: >>> >>> >>> http://svnbook.red-bean.com/en/1.7/svn.basic.in-action.html#svn.basic.in-action.mixedrevs >>> >>> I've tested this out and I get the error message but I *also* get a >>> helper diaog "Shall I update the working copy and retry?". If I run the >>> update the merge will be retried and it succeeds for me. So I think >>> TortoiseSVN is doing what it can to help. >>> >>> If you really don't want mixed revision WCs then you can probably create >>> a post-commit hook script that do svn update in the wc. YMMV. >>> >>> 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/c4783d8e-c80e-4adc-b38f-d80f6d34c387n%40googlegroups.com.
