collapse command removes a series of csets and puts the changes that are contained in those csets into the working files. The
-a argument is collapse is really what rev do you want to have as the new tip after the collapse.
bk collapse -aREV’ and ‘
bk undo -aREV’ have identical committed revision history after they complete. The difference is that collapse keeps all the modifications from the discarded csets and puts them in pending deltas and modified gfiles.
So assuming a straight line history the commands to merge 1.432 and 1.433 look something like this:
bk collapse -e -a1.431 # rev 1.431 will be the new tip rev
bk citool # create a new cset with the merge of the 2 removed
Your command should have removed only one cset and so allowing you to revise the top cset and create it again. Run ‘
bk citool’ to see those. If you run ‘
bk collapse -e -r+’ you should now remove one more cset and merge it into the changes that are pending for a new cset. Old bk users will recognize this as the same as ‘
bk fix -c’.
I can’t explain the nothing-before-2000 result, try just ‘
bk changes’. The -vv is very expensive might have had a problem.
The command works fine, what isn’t final is that the -e command to leave the new cset editing is required. The intention for the future is that without the -e it will automatically create the new cset after collapsing.