In general, it is a bad idea to have two RTC sandboxes associated with the same RTC repository workspace.   In particular, the local state in the sandbox assumes it is the only sandbox making changes to that repository workspace.   If another sandbox has made changes, you will have to resync the sandbox with the repository workspace, which is not an efficient operation.  Note: when the other sandbox tries to commit (check in) changes to the repository workspace, the skew will be detected, and you will be prompted to resync the sandbox.

So instead of having two RTC sandboxes associated with the same RTC repository workspace, you should have two RTC repository workspaces, one for each sandbox.   When you want to switch to the other sandbox (other laptop), suspend all of the outgoing change sets in the one sandbox, and resume them in the other (you actually only have to suspend the uncompleted change sets, since you can just accept the completed ones, but it is probably simplest to just suspend them all).