Why won't it check in???

[gregsohl]

I'm trying out some command line stuff - trying to get an understanding. I am having a couple of questions / problems I hope someone can help with.

Question 1

The first is a check-in problem. As you can see below, "cm fc" shows that I have one changed file. However, "cm ci" says there are no changes in the workspace. Even tried naming the item.

D:\Source\PlasticTest\Developer>cm fc
d:\Source\PlasticTest\Developer\TestFile1.txt

D:\Source\PlasticTest\Developer>cm ci
The selected items are about to be checked in. Please wait ...
Error: There are no changes in the workspace d:\Source\PlasticTest\Developer

D:\Source\PlasticTest\Developer>cm ci testfile1.txt
The selected items are about to be checked in. Please wait ...
Error: There are no changes in the workspace d:\Source\PlasticTest\Developer

D:\Source\PlasticTest\Developer>

What's up with that? I even bounced the PlascticSCM service just to be sure.

Then I had this additional strange sequence. There was a pending change in branch /Task8. I merged from /main into /Task8 (not shown). cm fc shows the pending changes to the directory and TestFile1.txt (which had a pending change before the merge from /main). The commit (cm ci) ran, but checked in ONLY the directory level change. cm fc still shows the pending change from TestFile1.txt, though again, it cannot be committed.

I was able to directly check in "TestFile1.txt" from the GUI without a problem.

D:\Source\PlasticTest\Developer>cm fc
d:\Source\PlasticTest\Developer
d:\Source\PlasticTest\Developer\TestFile1.txt

D:\Source\PlasticTest\Developer>cm ci
The selected items are about to be checked in. Please wait ...
Assembling checkin data
Validating checkin data
Uploading file data
Confirming checkin operation
Modified d:\Source\PlasticTest\Developer
Replaced d:\Source\PlasticTest\Developer\TestFile2.txt
Created changeset cs:27@br:/Task8@rep:Developer1@repserver:GSOHL-DT:8087

D:\Source\PlasticTest\Developer>cm fc
d:\Source\PlasticTest\Developer\TestFile1.txt

D:\Source\PlasticTest\Developer>cm ci
The selected items are about to be checked in. Please wait ...
Error: There are no changes in the workspace d:\Source\PlasticTest\Developer

D:\Source\PlasticTest\Developer>

Question 2

Also have a question on creating a branch from the command line. I'm attempting to create a task branch off /main. The "cm makebranch" command, when operating on /main, defaults to changeset 0 (zero). Since it would be typical that I would want to branch from the most recent changeset, what is the best way to get that and make a branch on that changeset? I guess I'm asking how I do the equivilant of the GUI's "Last changeset on parent branch". I don't want to have to look up and get the changeset number manually every time I do this, if I can help it.

Also, how do I create a branch using a Label as the parent from the command line? Our workflow relies heavily on labeling to keep in sync with database releases.

Question 3

There seems to be a difference in naming conventions for branches between the UI and the command line. When I create a branch off /main in the UI, the branch name is automatically prepended with /main, creating a branch name of /main/<new branch name>.

On the command line, the /main is not prepended.

Why?

Thanks.

Greg

[manu]

Hello Greg! Let's see:

Question 1:

It seems the file is changed, not checked out. Keep in mind that this two states are different for Plastic SCM. The changed item has a blue tick in the item decorator and the checked out has a red dot.

You can't checkin changed items from the command line without changing it to checkout, buuuuuut with some basic hacker stuff we can achieve it, for example:

> cm fc . | cm co -
> cm ci

BTW, we have another command much more powerful, "cm status --help". This status command can give you the same information as the pending changes view.

Our idea is to connect this command to the "cm ci" command, this will give us a complete support for all the items status from the command line, just the pending changes view does.

Question 2:

This one is easy

From a label:

cm mkbranch myBranch001 --label=BL001

From a changeset:

cm mkbranch myBranch002 --changeset=1

From the last changeset of the parent branch: Sorry, pending to do it.

Question 3:

Yes, you are right, when you are creating a branch from the GUI you are implicitly setting a parent, for example, if the base is a changeset the parent will be the branch that contains the changeset and the branch name will be appended to the new branch name. It's the Plastic SCM 3.0 style, where the branch names and relationships were very important (by design).

If you create a branch from the command line you need to type the whole branch name, this is more the 4.0 style where the branch names and relationships are not important.

[gregsohl]

Question 1

Thanks. I understand. The old heritage dies hard in Plastic.

I have my new script file, cmcommit.cmd that I placed in the Plastic client folder with that sequence in it.

Question 2

Thanks. Is there an easy command line action that can retrieve the latest changeset # for a branch?

Question 3

Consistency would be nice. Surprises (unexpected behavior) are not nice. Suggest keeping the behavior of your command line and GUI in sync with each release. Perhaps a configuration option for branch naming style would help to resolve this.

[gregsohl]

Question 1

I guess what the user guide says doesn't apply to the command line then?

Modify-Commit – You don’t need to declare your intention, just simply make a modification in your

workspace. Then, you use a commit command to send the change to the repository, creating a new

revision there.

[manu]

Question 1

I think that when the documentation is telling "Modify" it's actually referring to the Checkout operation.

I like your alias command!

Question 2

Yes!

cm find branch where name='scm003' --format={changeset} --nototal

Question 3

I totally agree with you, it can be confusing, I'll talk with the team regarding this.

[gregsohl]

Question 1

From your marketing Features page:

With transparent SCM, you don't need to tell Plastic SCM when you change things. Just edit your code, move or delete files, and Plastic SCM will detect the changes for you.

Apparently this does not mean the command line, since now I am having to manually tell the command line what files to check out before it can check them in.

[manu]

Yep, you are right.

The page is speaking about the pending changes view, it has an image of it on its left:

[gregsohl]

Regarding Question 3, parent branch name prepending:

I think it would be best to provide it as an option. In the GUI, add a checkbox to the create branch dialog that allows the user to select to prepend parent branch names or not. In the CLI, add an option.

A more granular option would allow 3 choices for prepending:

1. No parent name (new_branch)

2. The immediate parent only (/sub_parent/new_branch)

3. All parents (/main/sub-parent/new_branch)

[manu]

1. No parent name (new_branch)

This is the current behavior.

2. The immediate parent only (/sub_parent/new_branch)

This can be problematic since how can you distinguish between creating the branch from

/main/task001/HotFix1/test2

or

/main/task002/HotFix1/test2

with the cm mkbranch HotFix1/test2/Review1

3. All parents (/main/sub-parent/new_branch)

This is the current behavior.

[gregsohl]

Manuel,

I agree with your summation about choice #2. Just an idea, and likely not a good one.

However for 1 and 3, I disagree with your statement "This is the current behavior". It is true that #1 is the current behavior for the command line and #3 is the current behavior for the GUI, but neither is the universal current behavior.

Any idea on when we could have an option to specify?

Thanks.

Greg

[manu]

Hi Greg, the 1 and 3 are valid for the command line.

Now I'm a little bit confused about your desired behavior, can you give some examples about it and the option you would like to see. We can discuss about it.

[psantosl]

Regarding the branch naming conventions:

* From the GUI we do enforce the creation of child branches, although first level branches are useful and should indeed be used too: http://codicesoftware.blogspot.com/2012/05/using-first-level-branches-in-plastic.html

* From the CLI there's more freedom but it is all due to the less constrained environment the CLI is about.

At the end of the day, as Manu pointed, branch names are a convention, a way to arrange the entire branching namespace.

Since most users are GUI based, we considered keeping the same behavior of 3.0 and previous versions would be a good idea.

But introducing a check to select how the branch is going to be named can actually work.

Anyway, let's consider the following:

* If you create cm mkbr main/task001 -> the branch name is "task001", always. The thing is that the branch "task001" is assigned a "parent" called "main". Right now the parentship is only used for naming convention (the full name is the ancestor's names plus the branch name).

* If you run cm mkbr task001 -> the branch names is "task001" too, but the branch doesn't have any parents.

That being said:

* It would be possible to select whether the branch is child or not

* It wouldn't be impossible to say you're child of "integration" but not "main" if integration is child of "main"

Hope it makes it clearer