Can't accept active changesets from another workspace.

Work item 89594 requests the ability to accept an incomplete change set
into a workspace. Please feel free to add a comment indicating your
interest/support.

Note though, that it's not telling you to deliver the changes ... it's
just telling you to "complete" the change sets (delivering a change set
automatically marks the change set as complete).

The reason the system requires you to complete a change set is that
otherwise, you could be left with one state of the change set in some
workspaces/streams, with "later" states of that same change set in other
workspaces/streams. Most SCM systems don't care about that, since they
do not carefully maintain change-set semantics, but a change-set based
system like RTC does have to care.

An alternative would be to remove the concept of a change-set being
complete, and update the Pending Changes display to understand that one
of the change flows involves moving to a later or earlier state of a
change set (effectively, what is being requested in work item 89594).

Cheers,
Geoff

On 7/22/2011 4:23 PM, stus wrote:

I made changes to some code using workspace A connected to Flow Stream
S. I checked-in (not delivered) those changes and then went home. On
my home machine using workspace B also connected to S, I decided that
I wanted to do some more work on the pending changes just checked-in
from A. So, I set my flow stream of B to point to workspace A. The
pending change set from A was now visible from B but when I try to
accept it I get the following error:

Active change sets cannot be accepted. Please complete the change sets
or contact their owner.

I know it's telling me to deliver my changes from A but I don't want
to deliver them to S yet because they are not yet ready. I was
hoping to finish them from B and then deliver them to S this
weekend.

Completing or testing half baked work done on one machine using
another machine is an incredible common workflow for a developer
(especially when you are trying to test some changes on a different
platform.) In svn I would just have a branch for my
unfinished/untested changes and then pull them into wherever I wanted
to.

Why is doing something similar on RTC so hard?

Thanks for the reply. I guess because of my prior history with cvs/svn (and more recent experimentation with git) I'm not sensitive to the formal notion of changesets. To me, if it can be merged (ie. text source code) notions of 'state' (which probably derive more from the RTC's internal need to keep various things straight than the actual state of the source code) really should not get in the way of doing what I was attempting to do.

So if I were to mark it as 'complete' what does this imply in terms of the workflow I specified? That is, could I continue to make changes to my code once I got home via workspace B?

Yes, as soon as you get home, you would just accept that completed
change set and then continue making changes ... they would just go into
another change set. And if you are using work items (which you should
:-), you'd set that work item as your "current work", and the change
sets for that work item would all be associated with that work item.

Cheers,
Geoff

On 7/22/2011 11:53 PM, stus wrote:

Thanks for the reply. I guess because of my prior history with
cvs/svn (and more recent experimentation with git) I'm not sensitive
to the formal notion of changesets. To me, if it can be merged (ie.
text source code) notions of 'state' (which probably derive more from
the RTC's internal need to keep various things straight than the
actual state of the source code) really should not get in the way of
doing what I was attempting to do.

So if I were to mark it as 'complete' what does this imply in terms of
the workflow I specified? That is, could I continue to make changes
to my code once I got home via workspace B?

I made changes to some code using workspace A connected to Flow Stream S. I checked-in (not delivered) those changes and then went home. On my home machine using workspace B also connected to S, I decided that I wanted to do some more work on the pending changes just checked-in from A. So, I set my flow stream of B to point to workspace A. The pending change set from A was now visible from B but when I try to accept it I get the following error:

Active change sets cannot be accepted. Please complete the change sets or contact their owner.

I know it's telling me to deliver my changes from A but I don't want to deliver them to S yet because they are not yet ready. I was hoping to finish them from B and then deliver them to S this weekend.

Completing or testing half baked work done on one machine using another machine is an incredible common workflow for a developer (especially when you are trying to test some changes on a different platform.) In svn I would just have a branch for my unfinished/untested changes and then pull them into wherever I wanted to.

Why is doing something similar on RTC so hard?

I believe you can also suspend the change set and resume it in another workspace. Then you wouldn't have to create a new change set. Completing the change set is fine though. It's really just a preference of how you want to do things.

As far as I tried,
You can accept the CS as a patch by openning it's related WI and right-click -> accept.
Maybe the problem would be: two CS that contains the same modifications. So just discard the old one.

Completing or testing half baked work done on one machine using another machine is an incredible common workflow for a developer (especially when you are trying to test some changes on a different platform.) In svn I would just have a branch for my unfinished/untested changes and then pull them into wherever I wanted to.

Why is doing something similar on RTC so hard?

I just wanted to point out another alternative. All the solutions posted here are valid for the case when you work on "repository workspace A" on "machine A" and "repository workspace B" on "machine B"
ex:
-work-arounds for accepting incomplete change sets
-completing the change sets and accepting
-suspending/resuming change sets-
or creating/accepting a patch)

But from reading your original post, one interpretation could be simply that you are doing work on Machine A (in "repository workspace A"), and now you move to another machine ("B") and want to keep working on that same work.

As long as you check in all your local changes into "repository workspace A" there's nothing preventing you from perform a "Load" of "repository workspace A" on "machine B"... even if your change sets are not marked as complete, you can still re-load them on another machine... and continue to work exactly where you left off.
Some things to worry about are:

-if you have local changes in your "Eclipse Workspace A", (i.e not checked into a change set), then clearly loading that same repository workspace in "Eclipse Workspace B" will not pick up the local changes.... so just make sure you check everything in before you leave from work / home.

-It might be a pain having to re-load the repository workspace contents on a different machine (but this all depends on 'how much you load')

-It's also generally discouraged to have a repository workspace loaded in two different places simply because this is how you can get the repository workspace out of sync (which generally as a worst case the UI indicates this and requires you to re-load the repo workspace). However if you 'unload' the repository workspace before you leave because you know you need to load the repository workspace elsewhere, then this issue is avoided.

These steps are exactly what you mentioned in your first post:
"In svn I would just have a branch for my unfinished/untested changes and then pull them into wherever I wanted to."

branch = repository workspace
pull them into wherever = just perform a "load" of that repository workspace on another machine

Completing or testing half baked work done on one machine using another machine is an incredible common workflow for a developer (especially when you are trying to test some changes on a different platform.) In svn I would just have a branch for my unfinished/untested changes and then pull them into wherever I wanted to.

Why is doing something similar on RTC so hard?

I tend to disagree that it is hard on RTC, but a few things run differently there. Firstly, the equivalent to an SVN branch is more or less an RTC stream. However, an RTC workspace is very similar to an RTC stream, they are both containers for change sets. The RTC workspace only allows you to have active/incomplete changesets, manage suspended changesets and it can be loaded to a local sandbox. The similarities are that they are containers for completed changesets and as such can serve as flow targets.

Now, what you do is that you create an additional workspace from the same stream as the one you already have. Then, you connect those two workspaces as flow targets with each other. This allows you to move changes from both workspaces to each other and to deliver them to the stream. Note: delivering to a workspace is broken in RTC, it will cause the workspace to go out of sync. Instead, accept the according changeset, i.e. pull the change instead of pushing it.

Each one of the two workspaces is loaded on one of the two machines. If you want to move work from one to the other, you either complete the changeset (it remains in the workspace, you don't deliver it to the stream yet!) and you can then accept it from the other workspace. Alternatively, suspend the changeset and resume it from the other.

BTW: The idea as I understand it is that a changeset is exclusively owned while it is incomplete and while it can still be modified. That means it is only accessible to a single workspace, which in turn means that multiple workspaces don't have to coordinate access to it. Then, when you complete it, it can be shared by different workspaces, but in order to avoid synchronisation problems it is treated as immutable. This approach using exclusive access while writing and shared access without writing is e.g. also used by Java's string/stringbuilder (or was it stringbuffer?) class.

Lastly, you can also connect workspaces of different users with each other so that they can quickly share changesets even without an intermediate stream.

Uli

Note: delivering to a workspace is broken in RTC, it will cause the workspace to go out of sync. Instead, accept the according changeset, i.e. pull the change instead of pushing it.

Delivering to a workspace isn't broken. RTC doesn't track where workspaces are loaded so it is impossible to keep a sandbox updated. There are also checks to ensure you cannot deliver to another user's workspace.

I agree with Ulrich that from a customer's perspective, delivering to a
workspace is broken, in that it leaves the target workspace out-of-sync
(the fact that RTC doesn't track where workspaces are loaded is a reason
why it is broken, but that doesn't make it OK :-).

And there is a relatively easy fix ... provide a "pending set" for
delivery to a workspace (work item 36080).

Cheers,
Geoff

On 12/1/2011 8:38 AM, tmok wrote:

ulricheckhardtwrote:
Note: delivering to a workspace is broken in RTC, it
will cause the workspace to go out of sync. Instead, accept the
according changeset, i.e. pull the change instead of pushing
it.Note: delivering to a workspace is broken in RTC,
it will cause the workspace to go out of sync. Instead, accept the
according changeset, i.e. pull the change instead of pushing
it.

Delivering to a workspace isn't broken. RTC doesn't track where
workspaces are loaded so it is impossible to keep a sandbox updated.
There are also checks to ensure you cannot deliver to another user's
workspace.

I tried this option of accepting the incomplete chageset did not work for me in RTC 2.0

1. checked in a file in workspace A
2. From workspace B ---> changed the flow target to workspace A
3. In pending changes I was able to see the changeset C which was modified from workspace A
4. Tried to Accept the changes

it gave error Active change sets cannot be accepted. Please complete the change sets or contact their owner.
5. Opened the changeset C and changed the state to Complete (Done)
6. Again tried to accept from workspace B

it still gave the error ? Any idea does this work in RTC 2.0

Thanks