Undo "bk collapse -a ... -e"

Support
1

Hi.

I did a “bk collapse -a 1.432 -e” thinking that 1.432 and 1.433 were my last two commits, and they’d be merged. No such luck.

Now “bk changes -vv” doesn’t show me any commits prior to 1.357 and 8/20/2000. What?!?!

Clearly I did something wrong.

The man page suggests that what I did isn’t yet final, but I can’t figure out how to undo it if it isn’t final.

Thanks,

-Philip

1 Like
2

The 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.

A ‘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.

3

I can’t explain the nothing-before-2000 result, try just ‘bk changes’.

The same.

-Philip

4

I just peeked in BitKeeper/tmp/collapse.patch and realized I must have gotten the version numbers wrong because I’m seeing a lot more after 1.433.

So if there were more than just the two commits, how would I undo the collapse?

What does that change?

Thanks

5

To anyone reading this thread and getting worried, I got his repo put back together, I have a “fix” (it’s a hack but it worked) that did the work, Wayne knows the root cause, so we’ll have belt and suspenders in the next release.

6

And a big shout-out to Larry for handling that, late on a Friday, no less.

7

It was sort of fun, first time I felt like I had some juice in a long time. Fun to dig through the code, made me hate git more because BK makes that stuff easy.

Happy to help, we’re still here.

8

Just an update here.

The original problem might be considered a documentation bug because the user didn’t understand how collapse worked. Suggestions on how to improve the explanation here would be welcome.

However, that mistake should have been easy to reverse. There was indeed a bug in makepatch that was used to create the backup patch for the csets being removed by collapse. It failed to include was tags that were being removed from the repository.

@rick has a fix for this bug and we will be releasing a new version of bk with this fix soon.

My main stumbling block at the moment is because we have regressions that test for compatibility with older commercial releases of bk and the license keys in the regressions have expired. I am not sure I want to continue to maintain the license server functionality just to enable versions of bk that no one uses anymore.