Effect of checking-in unchanged files?

[elevan]

If a user has their client application configured to check-in unchanged files (version increments) what are the possible adverse affects at the server compared to if they were configured to undo the checkout if the file is unchanged instead? In my specific situation the user may have 40 files checked out of a directory, each of which has a size in the neighborhood of 2Gb (AutoCAD drawings), and may have modified 6 of the 40 files before checking-in the whole directory.

1. Does the check-in use more database space compared to the undo? Is another copy of the file placed in the database?
2. Does the check-in transaction take more time than the undo?
3. We are shadowing the directories. Will the check-in of an unchanged file cause an update to the shadow that wouldn't have been done with an undo checkout?

[lbauer]

1. Does the check-in use more database space compared to the undo? Is another copy of the file placed in the database?

If the file hasn't changed, Vault won't store the same copy twice. But file history would be incremented. If you are checking in hundreds of unmodified files a day, this would cause your database to grow unnecessarily.

2. Does the check-in transaction take more time than the undo?

Perhaps a tiny bit more, to update history and compare the checked-in file to the previous version on the server. Not something you'd usually notice.

3. We are shadowing the directories. Will the check-in of an unchanged file cause an update to the shadow that wouldn't have been done with an undo checkout?

Yes. It's a new version of the file, even if the contents are exactly the same.

Note: For optimal Vault performance, users should only check out files they plan to edit. The Vault server maintains a checkout list of all checked out files, and if this list gets too large (1500+ checkouts), performance could be adversely affected.