Whats the logic behind the required check-in comment? If I have several files checked out, including some new files to be added to the repository, and I click check-in at the solution level, the new files will be checked in but the existing files will be rejected (if I neglect to select a work item or provide a check-in comment).
This puzzles me because I reasoned that the new files would be seen as part of the over-all check-in operation and therefore rejected as well. It seems possible to me that you could still have half-baked check-ins if Fortress allows some of the files through but rejects the others.
Am I misunderstanding the boundaries of an atomic check-in/change set?
TIA
Atomic Check-ins/Required Check-in Comment
Moderator: SourceGear
-
dist0rti0n
- Posts: 112
- Joined: Mon May 01, 2006 10:50 pm
- Location: Birmingham, AL
I don't think Vault/Fortress has the notion of a changeset implemented... It's on the list of feature requests, though, so one more vote would be nice 
I'm putting off undoing what would have been a changeset, but finding out which check-ins belong to the "change set" is kind of a pain right now... I can look at the folder's history and see what happened around the same date/time, but I'm still afraid to do it...
Something like TRAC's timeline ( http://trac.edgewall.org/timeline ) would be great to have in Fortress...
I'm putting off undoing what would have been a changeset, but finding out which check-ins belong to the "change set" is kind of a pain right now... I can look at the folder's history and see what happened around the same date/time, but I'm still afraid to do it...
Something like TRAC's timeline ( http://trac.edgewall.org/timeline ) would be great to have in Fortress...
gabriel magana-gonzalez
If you have two pending changes for a repository that requires checkin comments, where one is a checkin and the other is an add file, then attempting to check in both of them without specifying a comment will fail.
If you have an add which is being automatically committed (using the Auto Commit option in the options dialog), then check in comments will not be enforced. If you wish adds to be considered as part of a larger change set, disable the Auto Commit option.
It is very important to state that _all_ commits are atomic. If you attempt to check in 500 operations together, and one of them fails, then all 500 changes are rejected by the server. No half-commits are allowed.
If you have an add which is being automatically committed (using the Auto Commit option in the options dialog), then check in comments will not be enforced. If you wish adds to be considered as part of a larger change set, disable the Auto Commit option.
It is very important to state that _all_ commits are atomic. If you attempt to check in 500 operations together, and one of them fails, then all 500 changes are rejected by the server. No half-commits are allowed.