Ticket #8 (defect)
Opened 3 years ago
Last modified 3 years ago
automatic vss database manipulation can be done within the same second
Status: assigned
| Reported by: | luedi | Assigned to: | toby (accepted) |
|---|---|---|---|
| Priority: | minor | Milestone: | 0.11.0 |
| Component: | vss2svn.pl | Version: | 0.11.0 |
| Keywords: | Cc: | ||
I wrote a few test scripts to simulate some buggy behavoir. The scripts are that fast in changing the database, that more than two actions have the same timestamp. This resulted in a messed up timesequence of actions. As long as we have to deal with user interactions, there shouldn't be any problem, but if someone has some build scripts, that manipulate the vss database ....
Change History
03/21/2006 12:35:43 AM: Modified by toby
- status changed from new to assigned.
- milestone changed from 0.10-alpha-2 to 0.10-beta-1.
03/21/2006 02:34:57 AM: Modified by ldavis
03/21/2006 06:01:46 AM: Modified by luedi
VSS doesn't have a problem with this, since it is file based and it does not have a unique revision number. I think you will have a problem, when you try to get things by timestamp. It will simply stop, when the first (or last (?)) version with the specified time is reached. But as long as you access the items by version number, everything should be fine.
04/11/2006 12:17:33 PM: Modified by toby
- priority changed from major to minor.
- version changed from 0.10.0 to 0.11.0.
- milestone changed from 0.10-beta-1 to 0.11.
Changing milestone to 0.11.
Dirk, do you know of any place in particular where this causes buggy behavior? I believe we are always retrieving by version number where possible.
04/11/2006 12:23:53 PM: Modified by luedi
The problem is not that we retrieve by version number. The problem is that we, due to the same timestamp of multiple actions, create a wrong sequence of the actions.
E.g. grab any of the testfiles attached to one of the other tickets and remove the "sleep" code. You will see that what I mean.
or take the following sequence:
add file.txt commit file.txt rename file.txt new.txt share new.txt
If run from a script all actions will have the same timestamp. Our ordering by importance, will move the share in front of the rename.
06/07/2006 04:39:17 AM: Modified by luedi
This is partially be solved in [241]
How does VSS cope with this situation? Or does it?