paul....@dynatrace.com
unread,Aug 13, 2018, 4:37:19 PM8/13/18Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to TortoiseSVN
Hi,
I want to report what I consider a bug.
Version: TortoiseSVN 1.10.1, Build 28295 - 64 Bit , 2018/07/15 12:14:12
What I do:
- Open the "commit" dialog
- Tag some files as "restore after commit"
- Edit them
- Click "Build Solution" in Visual Studio to make sure I didn't mess up
- Commit
- Continue working in Visual Studio
What happens:
After committing, the files I edited are being restored with their original change date (the change date they had when the backup was made). Since I did a build after temporarily changing the files for committing, that date is older than the date of the .o files. When I continue working after that, this can lead to errors (that can be very puzzling) because some .o files haven't been rebuilt.
What should happen:
After committing, the files I edited are being restored in such a way that their modification date is the date of the restore. (Overwriting the files instead of replacing them with the backup copy should work, so should touching the backup files before copying them over the modified originals.)
IMO a tool that works with source code should *never* change a file in a way that doesn't set the change date to the current date.
I don't know if the current behavior was intentional. If so, I'd request that this be made configurable, because the current behavior greatly reduces the value of the "restore after commit" feature for me.