Stefan schrieb am Freitag, 11. Dezember 2020 um 19:05:13 UTC+1: > ok, just spent two hours trying to find a way to show a proper diff for > such a "normal (+)" file, but then I realized it's simply not possible. > I try to explain: > Subversion has very weak support for renames/moves. While it *does* record > a move, it does so only in the revision the move occurred. Now, when you do > a merge, that move information is lost because a merge is basically > applying a diff to a working copy. So when you merge, the moved folder is > merged as "added" with the copy-from info set to the branch that's merged > in, and the old folder is simply deleted. > Which means the information that the folder got renamed is lost in the > merge. > > so basically there's nothing I can do here. > Sorry. >
Thank you for your effort. I am sorry to hear that it didn't help. > you don't have to lock that file: > the file is at a new location locally, so all other users don't have that file (yet). Only once you commit the merge and the moved folder/file, *then* you can lock the file because then it has a 'connection' to the repository. Yes, the added file is not yet in the repo, so of course it cannot be locked. But it is autotically maselected in the lock dialog, which should not be the case. And the local deleted files are still part of the repo, but they are not locked, because they don't appear in the lock dialog: > Other files, that are still in the repo, but moved / deleted in the working copy and not yet committed, are not part of the locking list. (me, 10.12.2020, 12:25:34) This would create an incomplete lock on the folder. > Subversion has very weak support for renames/moves. While it *does* record a move, it does so only in the revision the move occurred. Now, when you do a merge, that move information is lost because a merge is basically applying a diff to a working copy. So when you merge, the moved folder is merged as "added" with the copy-from info set to the branch that's merged in, and the old folder is simply deleted. I think we're talking about files, not folders, but that should be the same. And you said >the moved folder is merged as "added"<, but the moved file is not shown as "added", but as "normal", as shown in your test: > M 4 2 toknauss . > D 4 2 toknauss doc01.txt > A + - 4 toknauss folder_a > + - 4 toknauss folder_a\doc01.txt Regarding the file, this combination of actions is just wrong in my opinion: The original file was deleted. Okay. But the file exists at a new location after the commit, so if it got *deleted* at the original place, it must be *added* at another place (with or without reference to the old one). Otherwise it does not explain that the file still exists. If it was *deleted* only, then the file should have been gone and not exist anymore. > I'm working on a workaround the svn lib problem here when doing a diff-against-base. However the status will still be reported as normal. > And "added" would be wrong too: the file in relative to it's parent folder wasn't added at all but stayed the same. "Added" would not be wrong, because the file *was added* in the new parent folder. If it had *not* been "added", then the consequence must be that there was no *deleted* file either. But there *is* a delete file, so there also must be an *added* file. I am thinking about creating a bug report for the SVN lib, but I don't have any insight to the lib itself, since I don't use it. > so basically there's nothing I can do here. You can. I can contribute to a bug report, but I think you're the one who needs to create it. Please understand that it's not about offloading work to you, but if I was the one who starts a conversation with the developers of the SVN lib, then it basically is a ping-pong with 3 people, and I am in the middle, although I have the least participation in the whole process. I will assist you in convincing the SVN lib developers if necessary. > Subversion has very weak support for renames/moves Maybe the developers need to improve that support in order to achieve a correct behaviour. -- 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/bfc8b4e0-0cde-4b61-99ea-2e4fb1283345n%40googlegroups.com.
