I believe what you are calling a "clientspec" is what would be called a
"sandbox" or "file area" in RTC.

The most efficient way to work with RTC in this scenario is to have two
repository workspaces ... one for the desktop machine, and one for the
laptop machine.

Note that in RTC, a "checkin" is a "private" operation ... it persists
the changes you have made into the repository, but doesn't make them
visible to other team members until you "deliver" that change to the
team's stream. So best practice is to checkin all of your changes
before you leave that machine, both for reliability (in case that
machine dies or is stolen), and to avoid gratuitous branching.

In order to make this process very simple, RTC allows you to have an
arbitrary workspace as a "flow target" of your workspace. So when you
switch to another machine, accept the changes that you made from the
other machine's workspace.

There is one relatively minor annoyance here ... you can only
accept/deliver a change set if it has been "completed". So this means
that you have to complete the change-set in order to accept it into the
other workspace, so you will get a new change-set each time you "switch"
to another machine before having completed a given task. Commonly, you
try to reach a logical breaking point before going home, in which case
capturing all the work you've done up till that point in a separate
change set is usually not unreasonable.

But it is still annoying (:-) ... work item 59650 asks for this to be
supported ... please feel free to add a comment there to indicate your
interest/support.

Cheers,
Geoff

On 7/7/2010 12:08 PM, Danil wrote:

What is the RTC analog for a developer who does work on more than one
machine?

Usecase: During the day, developer is on his desktop machine. His
personal branch is loaded into the clientspec on this box. He makes
several edits here, without checking them in.

That night, he works from home - here he is using the clientspec on
his laptop. The changes he is making are related to the files he was
working on earlier, and includes some overlap. He checks this work
into his branch in the SCM.

The next morning, again on his desktop machine, he can pull down his
changes from the previous night. His clientspec is updated with the
changed files, with the files that were changed in both locations
marked for merge. He can resolve the conflicts in his desktop
environment and proceed.

How does this work in the RTC world?

Geoff's option is correct, but I use a much simpler workflow. You can load a repo workspace to different machine and this is supported, when you switch you simply reload and the reload is incremental and fast. Be sure to check-in your changes before switching, as we currently don't allow merging between a repo workspaces and a local file system that easily. We will also automatically detect that your have to reload when switching and prompt you to do so. In addition, the Pending Changes view shows a warning with a reminder.
Cheers,
Jean-Michel

As long as you reliably remember to check-in your changes before
switching, I agree with JM's approach. My concern in your case was that
you are not used to checking in changes until they are done, and so you
are at risk of facing the "don't allow merging between a repo workspace
and a local file system that easily" scenario.

Cheers,
Geoff

On 7/8/2010 12:52 AM, jlemieux wrote:

Geoff's option is correct, but I use a much simpler workflow. You can
load a repo workspace to different machine and this is supported,
when you switch you simply reload and the reload is incremental and
fast. Be sure to check-in your changes before switching, as we
currently don't allow merging between a repo workspaces and a local
file system that easily. We will also automatically detect that your
have to reload when switching and prompt you to do so. In addition,
the Pending Changes view shows a warning with a reminder.
Cheers,
Jean-Michel