A VCS shall be able to do intermediate commits.
This are commits which are marked incomplete. However they are distributed as usual.
The idea behind this is, if you do a minor edit (like you change a number) and you want to commit but not yet do a full revision, this then is a intermediate commit.
Note that a file can only have one intermediate commit state within a work set. If you need more, you must branch the intermediate revision (this branches at the previous revision and creates an intermediate commit) or create another work set. This means for comments on commits, those are then gathered into one single block, not into several intermediate blocks.
Note that previous intermediate commits vanish (semantically) as soon as you add a new intermediate commit (or do a commit). This is, you cannot undo a intermediate commit by reverting to a previous intermediate commit. This is by purpose. If you need that, do not use intermediate commits, it's that simple!
This also means, you will not see any intermediate commit if you look into the revision tree, except for situations where the intermediate commit is the last version.
The idea behind this is as follows:
- The devel branch you work in is not backed up. To do a backup (something which is worth backupping) you do a intermediate CI.
- Developers can fetch the intermediate commit state from other developers. By default they only fetch it, if it is theirs.
- If a new revision is fetched, the intermediate commits are automatically reverse-applied to the current revision, then the update is done, then the intermediates are applied again. This is, the intermediate changes are sticky relatively to the revision checked out. However they are uncommited after such an update (this is a 3-file-merge is done). If a CI is done, the new intermediate commit is marked as successor of the previous one. This is for more easy cleanup.
- People not interested in intermediates can CO the last HEAD without intermediates. This is the default for public access.
- People interested in the latest situation can do an update to intermediates. Either the intermediates are fetched by several file versions in parallel, or an n-way local merge is done according to age of the intermediates or the sequence of the update done. It's straight forward.
- Important is: It must be easy. There must be a "cleanup intermediates" command, such that all intermediates are deleted, except the latest one which is a successor of all previously ones. This is local to branches, of course, so no intermediates are deleted if they are in an active HEAD.
-Tino, 2008-02-08