We have one file that has been very slow lately during check-in. The status says "Ending Transaction ..." for several minutes. It seems to be only this one file (all other files are working fine).
This particular file has approximately 140 versions, while most of the other files have 10-30 versions. This file is also approximately 5000 lines in length. Do either of these (number of versions or length of file) have direct impact on check-in performance? Or is there some sort of "state" (Vault hidden folders) that I could clear on my client to make it go faster? Is the Vault server trying to do an automatic merge on the server (if so, can I turn that off)?
One file particularly slow on check-in
Moderator: SourceGear
If the messages pane says "Ending transaction", then the delta that describes the changes from the baseline is completely uploaded, and the client is simply waiting on the server to put the changes into the database.
The the size of the file and the size of the delta (bytes changed since last version) will both have an impact on the time it takes for a transaction to complete on the server. 5000 lines (assuming a full 80 characters per line, which is extremely dense code) is only about 390 KB, so I'm not sure why it's taking so long. What kind of CPU and memory resources does your server have?
The Vault server never automatically merges any changes, like VSS would do. The client is only allowed to submit deltas to the server that are based off the latest version in the repository. If the file is too old, the server doesn't allow the checkin, and the client must perform the merge action (using the GUI tool or the automatic merge feature of Get Latest Version). Once the server gets the delta, it needs to apply it to its latest version of the file to create the new version, then insert the new version into the database. I don't know the exact computational efficiency of this operation, and I don't think it's a function of the number of previous versions, but it shouldn't degrade to O(horrible) for a file this small.
The the size of the file and the size of the delta (bytes changed since last version) will both have an impact on the time it takes for a transaction to complete on the server. 5000 lines (assuming a full 80 characters per line, which is extremely dense code) is only about 390 KB, so I'm not sure why it's taking so long. What kind of CPU and memory resources does your server have?
The Vault server never automatically merges any changes, like VSS would do. The client is only allowed to submit deltas to the server that are based off the latest version in the repository. If the file is too old, the server doesn't allow the checkin, and the client must perform the merge action (using the GUI tool or the automatic merge feature of Get Latest Version). Once the server gets the delta, it needs to apply it to its latest version of the file to create the new version, then insert the new version into the database. I don't know the exact computational efficiency of this operation, and I don't think it's a function of the number of previous versions, but it shouldn't degrade to O(horrible) for a file this small.
Shaw Terwilliger
SourceGear LLC
`echo sterwill5sourcegear6com | tr 56 @.`
SourceGear LLC
`echo sterwill5sourcegear6com | tr 56 @.`