Auto-Commit does not work?
Moderator: SourceGear
Auto-Commit does not work?
In Options/Check In, I have "auto-commit after each operation" on. In Vault client, I delete a folder. Then in Pending Change Set I see Delete Folder operation as pending, and I can right-click it and "commit selected operations". Is that right?
Vadim Rapp
Check under Tools->Options->Concurrent Development Style to see if Auto-Commit is checked there, too.
If it's checked in both places, but still isn't automatic, then what version of Vault are you using?
Is there anything in the Messages tab that might indicate why the commit didn't happen?
Do file operations automatically commit and not folder operations?
If it's checked in both places, but still isn't automatic, then what version of Vault are you using?
Is there anything in the Messages tab that might indicate why the commit didn't happen?
Do file operations automatically commit and not folder operations?
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager
Yes, it is.lbauer wrote:Check under Tools->Options->Concurrent Development Style to see if Auto-Commit is checked there, too.
If it's checked in both places, but still isn't automatic, then what version of Vault are you using?
3.0.6
when I start Vault Client (after I deleted the folder X earler and closed Vault), I see the following:Is there anything in the Messages tab that might indicate why the commit didn't happen?
X does not appear in the project tree
The lower part has this on the "pending change" tab:
Item=$/X , type = "delete folder", repository path = $/X
The tab "messages" is empty
The shortcut menu opened on the right-click on the item in pending change set list has "commit selected operations", but it does not have "undo selected operation", for which there's an icon above the tab (design inconsistency?). When I pressed that icon, the item disappeared from the pending change list, but did not appear in the project tree above, i.e. it was not restored, and no error message was given.
The list "pending change" also has many file operations with types "modified" and "unmodified". How to find out if they commit or not? All check-ins and check-outs always work without a problem. What does it mean to commit, what is supposed to happen?Do file operations automatically commit and not folder operations?
Vadim Rapp
-
Guest
Items appear in the pending change set because they are "pending" -- they haven't been committed to the repository yet. You might think of a commit as a checkin of a change to the repository.
If you use the option to "Auto-commit" you may still have items in the pending change set.
When you checkout files, they appear in the pending changed set as "Unmodified." If you checkout a file and edit it (but don't check it in), it now appears "modified" in the pending change set. When you check in the file, it will no longer appear in the pending change set.
If a commit fails for some reason, there will be a message in the Messages tab that explains why.
For instance, when you try to delete folder that contains checked out files, this will fail. The item
Item=$/X , type = "delete folder", repository path = $/X
will remain in the pending change set.
If you checkin all the files in the folder and try to delete the folder again, this time the operation will succeed and be automatically committed. However the previous failed delete operation will still be in the pending change set. You would have to use "undo" (arrow icon) to eliminate it from the pending change set.
You can avoid "orphaned" items in the pending change set by correcting the problem that prevents the commit, and then trying to re-commit the operation from the pending change set, rather than doing the operation again.
For instance, if a folder delete fails, you would checkin any files in that folder, then commit the folder delete item in the pending change set, rather than doing another folder delete from the folder tree.
If you use the option to "Auto-commit" you may still have items in the pending change set.
When you checkout files, they appear in the pending changed set as "Unmodified." If you checkout a file and edit it (but don't check it in), it now appears "modified" in the pending change set. When you check in the file, it will no longer appear in the pending change set.
If a commit fails for some reason, there will be a message in the Messages tab that explains why.
For instance, when you try to delete folder that contains checked out files, this will fail. The item
Item=$/X , type = "delete folder", repository path = $/X
will remain in the pending change set.
If you checkin all the files in the folder and try to delete the folder again, this time the operation will succeed and be automatically committed. However the previous failed delete operation will still be in the pending change set. You would have to use "undo" (arrow icon) to eliminate it from the pending change set.
You can avoid "orphaned" items in the pending change set by correcting the problem that prevents the commit, and then trying to re-commit the operation from the pending change set, rather than doing the operation again.
For instance, if a folder delete fails, you would checkin any files in that folder, then commit the folder delete item in the pending change set, rather than doing another folder delete from the folder tree.