SCM create changeset doesn't work after moving to version 3.2.100
Hi,
I recently moved my SCM client from version "version 3.0.2.v20110831_0247" to "version 3.2.100.v20140114_0303".
I have only one component xyz in my sandbox D:\RTC\Main.
This command works in version 3.0.2, but no longer works in 3.2.100.
It will throw below error message:
Problem running 'create changeset':
Cannot determine which component to create change set in. Specify a component.
When I added --component, the command works, and the changeset was created but it DID NOT move the unresolved items to the changeset as it would do in the past.
Thanks,
Kian
I recently moved my SCM client from version "version 3.0.2.v20110831_0247" to "version 3.2.100.v20140114_0303".
I have only one component xyz in my sandbox D:\RTC\Main.
This command works in version 3.0.2, but no longer works in 3.2.100.
scm --config D:\Automation\login create changeset -d D:\RTC\Main "My Change Description"
It will throw below error message:
Problem running 'create changeset':
Cannot determine which component to create change set in. Specify a component.
When I added --component, the command works, and the changeset was created but it DID NOT move the unresolved items to the changeset as it would do in the past.
scm --config D:\Automation\login create changeset -d D:\RTC\Main "My Change Description" --component xyzPlease help me to identify if this is a behavior change or a defect? If this is the new behavior, please advise how I could move hundreds of unresolved items to the changeset.
Thanks,
Kian
Accepted answer
If I remember correctly "create changeset" subcommand will try to figure out the component if you are running the subcommand within the context of the component directory in the sandbox. In your case D:\RTC\Main seems to be the root of the sandbox. If you provide a path that is shared to the component in the -d option then it should automatically figure out the component you are working on else you need to specify it explicitly as part of the --component option.
Also, "create changeset" should just create the change set and should never checkin the changes. I don't think that was ever the behaviour. To checkin the changes, you can just specify 'scm checkin <folder>' and it should checkin all the unresolved changes below that folder. The thing I am not sure is whether the recursive checkin was introduced in 3.x or 4.x onwards.
The checkin subcommand should also create the change set automatically if there isn't an active change set.
Comments
Thanks. I think the behavior has changed. It does not automatically figure out the component from the -d option. I have to specify the --component option even though I use -d option. That used to work in version 3.0.2, but not anymore in version 3.2.
I was trying to the unresolved files into the changeset. Just realize that the checkin command will move all the unresolved files to the highest available changeset number.
Now, all my commands work: (a) Check change set (b) Checkin (c) Deliver
CREATE Change Set:
Before
scm create changeset -d D:\RTC\Main "test"
After
scm create changeset -d D:\RTC\Main "test." --component xyz
CHECK-IN:
scm checkin --delim-consistent -d D:\RTC\Main .
DELIVER:
scm deliver -d D:\RTC\Main