|
BizarroAzrael posted:A guy ran an SVN Update on his project last night after committing a number of changes. The changed files came up as conflicted and are now marked as unversioned in the directory, having apparently reverted to how they were priot to him making changes, so he has to delete them and revert the folder, which results in him getting the files with his committed changes from the previous day. I've had several people run the same update script for a few weeks now, and this is the first time I've come across this. I'm no guru, but could you elaborate on what this "update script" does more specifically? Usually, SVN won't (shouldn't) let you perform a commit if your working copy is out-of-date (to avoid repository conflicts on stuff that's been committed by other people), but you're telling us that he first committed and then updated, so it sounds like that wasn't the case.
|
#
¿
Aug 26, 2009 17:53
|
|
|
|
| # ¿ Apr 29, 2024 09:42 |
|
|
BizarroAzrael posted:He made some changes, committed them and did a few more local changes before leaving once more and running another overnight update. He was the only one changing these files (pretty sure he was getting locks for everything) and when the update ran they were conflicted. Since he had local, non-committted changes, is it possible that the script decided to update to a non-HEAD revision, one that was -before- his commit, for instance? I can't see how SVN would willingly take a file out of version control - does he still have his .mine conflict files?
|
|
#
¿
Aug 26, 2009 19:13
|
|