Yes, despite of the fact that most of use use Plastic from its excellent graphical user interface (check the one for version 2 at codice's blog, it can be entirely used from the command line.
And that's exactly what I'll be talking about, how to use plastic from the command line!
Basic repository
To create or remove plastic repositories you just have to use
- cm mkrep to create a new repository
- cm rmrep to remove an existing repository
Yes, there aren't commands to do housekeeping tasks such as check repository for errors, repack it or stuff like that... it is not needed!
Examples
Create a new repository. Consider your server is on machine plastic listening at port 8084 (the default). Then you'd have to type:
$ cm mkrep plastic:8084 mynewrep
To create a new repository named mynewrep. That's it!
If later on you want to get rid of it, type the following:
$ cm rmrep mynewrep@plastic:8084
Done.
Individual Developer
To work on a daily basis you'd need to know how to create a workspace (you won't be doing this on a daily basis but you should need to do it at least once in your lifetime), add contents to your repository, check elements in and out, and switch to an specific branch.
- cm mkwk will create a workspace
- cm add will add contents to a repository
- cm ci will check in files and directories
- cm co will check them out
- cm mkbr to create a new branch
- cm stb will help you switching to another branch
Examples
Create a new workspace:
$ cm mkwk myworkspace .
Will create a new workspace on the current directory
Populate the workspace with contents and add it under source control:
Inside your recently created and blank workspace:
$ tar zxf samplecode.tar.gz $ cm co . $ cm add -R . $ cm ci -R .
Will unpack some code, check out the root item, add everything and check in everything.
If you're working on a newly installed Plastic system you'd probably added all the contents into the main branch of the "default" workspace. How do you know that? Take a look at your selector with the ss command:
$ cm ss
Will show your current selector and tell you in which branch and repository you're working on.
Create a new branch:
Ok, so you're working in main, you just have added all your project's content under version control, and now you want to create a bugfix branch. Easy:
$ cm mkbr br:/main/bug_fix001 -c="This is my bugfix branch"
The comment is optional, and you've just created a new bug_fix001 branch which is a child of the main branch. What does it mean? Well, if your current version control system doesn't support branch inheritance... just throw it away! :-)
bug_fix001 actually inherits from main, which means it will take revisions from main when it doesn't find a rev in the branch itself. Let's see it with an example.
$ cm stb br:/main/bug_fix001
And know your workspace gets updated to work on branch bug_fix001
$ cm co code/mycode.c
To tell plastic you'll be making some changes on mycode.c No!! checkout is not blocking, so don't think it reminds you SourceSafe. In plastic you've to tell the system you're modifying a file before actually doing it, but it doesn't mean it blocks the revision... you could do as many parallel changes as required.
Ok, modify the file and check it back in:
$ cm ci code/mycode.c
What's the bug_fix001 branch content right now? Ok, it just contains code/mycode.c, the rest of the project's content is inherited from main. Easy, uh?
Integrator
So, you're an integrator, right? Ok, so your job is taking changes from your colleagues and integrate them back together to create a new release.
Ok, check the following commands:
- cm merge to merge from a branch, a changeset, a label...
- cm ci to check in changes. You already knew this one!
Well, the first step will be configuring your workspace for the integration. You want to integrate changes back on main? Ok, then "go to main":
$ cm stb br:/main
Well, you're done! Now, you want to integrate bug_fix001.
$ cm merge br:/main/bug_fix001
will show you a list of the files and directories to be merged
$ cm merge br:/main/bug_fix001 --merge
will actually do the merge.
Plastic will solve the conflicts and the modified files will be left in check out state so you can decide whether you want to commit them or not.
If a manual merge is needed the three-way merge tool will pop up.
If you don't like the included three-way merge tool (you're a fool) then you can configure another one in the client.conf client configuration file.
Once all your changes are done, check in everything:
$ cm fco --format={4} | bcm ci -
Do you want to label the newly created release:
$ cm mklabel version_00 $ cm label lb:version_00 -R .
Wrapping up
Well, it seems I finally needed only 10 commands instead of 20!
If you need more information just take a look at www.plasticscm.com or the codice's blog
