We're having major issues with our current version of Vault (Client and Server both 3.1.7.3719). I've posted a seperate thread about Get Latest Version, and we're also having problems with modified files not showing up in the Pending Changes Set. However, this bug seems quite critical.
This morning, I did a "Get Latest Version" and updated my local copy (I actually did it several times, due to the bug mentioned in my other thread). Everything was up-to-date.
One of my colleagues modified a folder and committed them (we're using CVS mode by the way). A while later, those files appeared in *MY* modified list, and if I commit them, I'm sure it'll "undo" his changed by overwriting them with my stale copies.
Here's a screenshot showing the problems. My local files have not been modified since I pulled them out this morning, and the ones in the repository clearly have a later date.
If I just committed them (as I often do, after a long day of changing many folders), it's likely my colleagues changes would be blown away.
I have the Vault client logging turned on (the file's quite big!), which I can email if you give me an address.
Major issues - vault trying to overwrite colleagues changes
Moderator: SourceGear
Major issues - vault trying to overwrite colleagues changes
- Attachments
-
- Major Vault Issues
- vault issues.JPG (221.63 KiB) Viewed 6218 times
Last edited by link on Fri Mar 24, 2006 3:00 am, edited 1 time in total.
They're both the same (C:\Source). They're inherited right the way down the tree (you can see most of the path in the top-right of the screenshot).
I think I've did a "Get Latest Version" not long after my colleague committed, so it looks like Vault failed to get my colleagues copy out,and then decided my copies were latest (possibly touching them while thinking about checking them out?), so this may be related to the other thread I started.
There's only one line even mentioning the file default.cfg (highlighted in the screenshot) in the log. Here's that line (and the few around it):
16/03/2006 12:34:43 <mutex>: [Watcher:636] Took mutex 1416
16/03/2006 12:34:43 <wf>: [Watcher:636] wf C:\Source\Testing\Automated\Mercury Tests\Platform\Questionnaire\Data Integrity\SetNumericAnswersToNull\Action2 mutex locked
16/03/2006 12:34:43 <mutex>: [Watcher:636] Released mutex 1416
16/03/2006 12:34:43 <wf>: [Watcher:636] wf C:\Source\Testing\Automated\Mercury Tests\Platform\Questionnaire\Data Integrity\SetNumericAnswersToNull\Action2 mutex released
16/03/2006 12:34:43 <wf>: [Watcher:636] wf for C:\Source\Testing\Automated\Mercury Tests\Platform\Questionnaire\Data Integrity\SetNumericAnswersToNull\Action2 created
16/03/2006 12:34:43 <mutex>: [Watcher:636] Created mutex 1432
16/03/2006 12:34:43 <mutex>: [Watcher:636] Took mutex 1432
16/03/2006 12:34:43 <wf>: [Watcher:636] wf C:\Source\Testing\Automated\Mercury Tests\Platform\Questionnaire\Data Integrity\TestClearingDateQuestions mutex locked
16/03/2006 12:34:43 <eol>: [GUIClientWorkerThread:3184] No EOL conversion performed onC:\DOCUME~1\DANIEL~1\LOCALS~1\Temp\vaultTmp\Testing\Automated\Mercury Tests\Platform\Reporting\Formatted Reports\ReportingBooleanValuesXorBlank\default.cfg
16/03/2006 12:34:43 <mutex>: [Watcher:636] Released mutex 1432
16/03/2006 12:34:43 <wf>: [Watcher:636] wf C:\Source\Testing\Automated\Mercury Tests\Platform\Questionnaire\Data Integrity\TestClearingDateQuestions mutex released
16/03/2006 12:34:43 <wf>: [Watcher:636] wf for C:\Source\Testing\Automated\Mercury Tests\Platform\Questionnaire\Data Integrity\TestClearingDateQuestions created
16/03/2006 12:34:43 <mutex>: [Watcher:636] Created mutex 1336
16/03/2006 12:34:43 <mutex>: [Watcher:636] Took mutex 1336
16/03/2006 12:34:43 <wf>: [Watcher:636] wf C:\Source\Testing\Automated\Mercury Tests\Platform\Questionnaire\Data Integrity\TestClearingDateQuestions\Action4 mutex locked
16/03/2006 12:34:43 <mutex>: [Watcher:636] Released mutex 1336
16/03/2006 12:34:43 <wf>: [Watcher:636] wf C:\Source\Testing\Automated\Mercury Tests\Platform\Questionnaire\Data Integrity\TestClearingDateQuestions\Action4 mutex released
16/03/2006 12:34:43 <wf>: [Watcher:636] wf for C:\Source\Testing\Automated\Mercury Tests\Platform\Questionnaire\Data Integrity\TestClearingDateQuestions\Action4 created
16/03/2006 12:34:43 <mutex>: [Watcher:636] Created mutex 872
(Is it right that the path is wrong in the bold line??)
I think I've did a "Get Latest Version" not long after my colleague committed, so it looks like Vault failed to get my colleagues copy out,and then decided my copies were latest (possibly touching them while thinking about checking them out?), so this may be related to the other thread I started.
There's only one line even mentioning the file default.cfg (highlighted in the screenshot) in the log. Here's that line (and the few around it):
16/03/2006 12:34:43 <mutex>: [Watcher:636] Took mutex 1416
16/03/2006 12:34:43 <wf>: [Watcher:636] wf C:\Source\Testing\Automated\Mercury Tests\Platform\Questionnaire\Data Integrity\SetNumericAnswersToNull\Action2 mutex locked
16/03/2006 12:34:43 <mutex>: [Watcher:636] Released mutex 1416
16/03/2006 12:34:43 <wf>: [Watcher:636] wf C:\Source\Testing\Automated\Mercury Tests\Platform\Questionnaire\Data Integrity\SetNumericAnswersToNull\Action2 mutex released
16/03/2006 12:34:43 <wf>: [Watcher:636] wf for C:\Source\Testing\Automated\Mercury Tests\Platform\Questionnaire\Data Integrity\SetNumericAnswersToNull\Action2 created
16/03/2006 12:34:43 <mutex>: [Watcher:636] Created mutex 1432
16/03/2006 12:34:43 <mutex>: [Watcher:636] Took mutex 1432
16/03/2006 12:34:43 <wf>: [Watcher:636] wf C:\Source\Testing\Automated\Mercury Tests\Platform\Questionnaire\Data Integrity\TestClearingDateQuestions mutex locked
16/03/2006 12:34:43 <eol>: [GUIClientWorkerThread:3184] No EOL conversion performed onC:\DOCUME~1\DANIEL~1\LOCALS~1\Temp\vaultTmp\Testing\Automated\Mercury Tests\Platform\Reporting\Formatted Reports\ReportingBooleanValuesXorBlank\default.cfg
16/03/2006 12:34:43 <mutex>: [Watcher:636] Released mutex 1432
16/03/2006 12:34:43 <wf>: [Watcher:636] wf C:\Source\Testing\Automated\Mercury Tests\Platform\Questionnaire\Data Integrity\TestClearingDateQuestions mutex released
16/03/2006 12:34:43 <wf>: [Watcher:636] wf for C:\Source\Testing\Automated\Mercury Tests\Platform\Questionnaire\Data Integrity\TestClearingDateQuestions created
16/03/2006 12:34:43 <mutex>: [Watcher:636] Created mutex 1336
16/03/2006 12:34:43 <mutex>: [Watcher:636] Took mutex 1336
16/03/2006 12:34:43 <wf>: [Watcher:636] wf C:\Source\Testing\Automated\Mercury Tests\Platform\Questionnaire\Data Integrity\TestClearingDateQuestions\Action4 mutex locked
16/03/2006 12:34:43 <mutex>: [Watcher:636] Released mutex 1336
16/03/2006 12:34:43 <wf>: [Watcher:636] wf C:\Source\Testing\Automated\Mercury Tests\Platform\Questionnaire\Data Integrity\TestClearingDateQuestions\Action4 mutex released
16/03/2006 12:34:43 <wf>: [Watcher:636] wf for C:\Source\Testing\Automated\Mercury Tests\Platform\Questionnaire\Data Integrity\TestClearingDateQuestions\Action4 created
16/03/2006 12:34:43 <mutex>: [Watcher:636] Created mutex 872
(Is it right that the path is wrong in the bold line??)
If you do a diff against the repository version or against the baseline, do the files being reported as edited show any actual differences in content?
By default, Vault checks the date time stamp of a file to determine whether it is edited or not. It is possible the files were touched by some program. Note that you can change this in the Options (Local Files) to use CRCs to determine whether a file has been edited.
The EOL thing probably isn't a problem, as it looks like that is the temp folder used to process the file before moving it to the working folder. However, do all the files you are having troubles with have the EOL message? Do those files have a different EOL type set in their properties?
Also, I think the working folder question Linda asked is whether or not you and your collegue are using the exact same working folder (e.g. using a shared disk, not just whether the paths on your different machines are the same). Using a shared disk as a working folder for 2 different people will cause lots of problems.
By default, Vault checks the date time stamp of a file to determine whether it is edited or not. It is possible the files were touched by some program. Note that you can change this in the Options (Local Files) to use CRCs to determine whether a file has been edited.
The EOL thing probably isn't a problem, as it looks like that is the temp folder used to process the file before moving it to the working folder. However, do all the files you are having troubles with have the EOL message? Do those files have a different EOL type set in their properties?
Also, I think the working folder question Linda asked is whether or not you and your collegue are using the exact same working folder (e.g. using a shared disk, not just whether the paths on your different machines are the same). Using a shared disk as a working folder for 2 different people will cause lots of problems.
If I show diff, it shows the repository as expected (ie. the version my colleague committed), and my local copy shows the old code (Get Latest Version certainly didn't work!!).
We're using the same folder paths, but not the same disk - we're aware that would cause massive problems. This same problem has also occured on another colleagues machine (he sees the same files saying he's modified them, when it actually wants to put the old versions over the new ones!), so it's not isolated to my machine.
We're using the same folder paths, but not the same disk - we're aware that would cause massive problems. This same problem has also occured on another colleagues machine (he sees the same files saying he's modified them, when it actually wants to put the old versions over the new ones!), so it's not isolated to my machine.
Let me know if changing the "perform repository deletions" option as a result of this thread http://support.sourcegear.com/viewtopic.php?t=5750 seems to make this problem go away, or whether there is more to it.
As mentioned in that thread, the workaround is more dangerous than the actual bug (we'd rather have files missing and know to do another Get Latest Version than edit stale files).
This bug has caused us to overwrite more work this week, and although we can roll this back in Vault, if it goes unnoticed, we're losing work.
Is there anything we can do to help identify this problem? It's rather critical we can work without having to commit every file individually after modifying it.
This bug has caused us to overwrite more work this week, and although we can roll this back in Vault, if it goes unnoticed, we're losing work.
Is there anything we can do to help identify this problem? It's rather critical we can work without having to commit every file individually after modifying it.