RT @MintheG: #klaagtweet
Mijn website kon ik bij SimpleSite grotendeels zelf doen. Ik had alleen hulp nodig bij het plaatsen van de afbeeld… 1 hour ago
Spending most of your career as an independent contractor, you bump into a lot of toolchains.
Part of those toolchains usually involved (and by now surely should involve) version control for both development and infrastructure configuration management.
The really good part is the branch overview (called Branch Explorer) in the PlasticSCM UI, as it is:
horizontal, which makes it far easier to walk branches over time (as screens tend to have more horizontal space than vertical, and the interesting branches tend to live longer than boring ones), a good example of the difference is at [WayBack] Gamasutra: Matt Schoen’s Blog – I Gave PlasticSCM a Try of which I included screenshots further below.
the arrows pointing from a commit to the source commits, which makes it more intuitive to find where stuff comes from:
[WayBack] Plastic SCM vs Git – Pablo Santos Luaces – Medium (note that merging in git does not force you to loose the branche: that’s a choice you make while merging)
They also have frequent updates, which however are hard to discover because there is no built-in update mechanism that notifies you of them.
Those updates are badly needed, because I kept bumping into bugs. Which is odd, because I bumped into far less issues when using UI layers for SVN, TFS, Mercurial and git (SourceTree being a major exception, but they seem to have recovered from a long period of bad versions a few years back).
So here are some of my gripes, that might have been fixed by now.
Main console tool
Let’s start with the main console tool called cm which lacks a lot of documentation, and the documentation there is, is sparse.
The main documentation is in [WayBack] Plastic SCM version control · CLI guide: “Tutorial that shows you how to use Plastic SCM from the command line interface” which starts with this note:
Remember, you can always get more info about all the commands using cm help command_name.
Run the cm help objectspec command to learn about the definition of the different object specs supported by Plastic.
When using --errorformat + --ignorefailed with “add” all ignored errors are not formatted (either with --format or --errorformat). I don’t know if they’re not considered as errors internally but they show up in the output with a localized human readable string, and that’s not very convenient for automated parsing.
--silent is not really silent (at least with “add“)
Getting current status: always use cm status --all
Examples:
cm status
(The command will print the working changeset and also the items that are
checkedout, added, copied, replaced, deleted and moved.)
cm status --all
(The command will print all item types changed in the workspace but not
the ignored ones.)
in practice it does not, so you have to always run cm status --all: I regard this as undocumented.
Starting with the last bit, as it crucially important to allow for querying the various object types (that you for instance need with cm find branches or cm find changesets).
Executing it reveals the output is almost meaningless, as cm help objectspec ends with describing what it intents to describe, but then stops:
Describes how to write object specs.
Usage:
cm help objectspec
To get all the information about how to build object specs.
Several Plastic SCM commands expect 'object specs' as input to refer to a
given object (typically a branch, changeset, repository, etc).
This documentation describes the different "specs" available and how to
build them.
Finding changesets
It takes a while go get a feel for how to find stuff. This finds changesets more recent than a certain date, by two people:
find changeset where date > '31-10-2018' and (owner = 'jeroen' or owner = 'edwin')
Finding commands
Any software configuration management tool as a lot fo functionality, usually all executable from the command-line.
I was hoping PlasticSCM was no exception, as parts of the documentation hint that cm is the central piece. It is, but finding how to use that functionality is a nightmare. The best way to get information, is to address @plasticscm in your tweet. Usually either of these accounts will follow-up:
Remember, you can always get more info about all the commands using cm help command_name.
The quote is about “all commands”, but forgets that cm help command_name does not list commands, as there is another very important command that indeed lists almost all the commands: cm showcommands --all which has a long result quoted in this gist.
The cm help command_name is not about all commands. It is about help for any command having documentation.
Finding where you are
Before going back to the all versus any, lets focus on a key aspect in version control: finding out where you are on the command-line from the perspective of the version control structure.
Of course you are in the current directory on the command-line, but what does the version control system think this is bound to on the version control side?
For Mercurial, this for instance includes hg paths to find the repository and hg branch to find the branch and hg id -i to get the hash of the current commit (changeset) or hg parent to get the full commit information.
For git, you can respectively use git remote -v, git branch (or git rev-parse --abbrev-ref HEAD), and git rev-parse HEAD or git log -1.
So what about PlasticSCM? What branch am I in?
There is the cm status command showing this when your current directory is bound to a PlasticSCM repository:
The crucial part missing here is the current branch.
Here you find out that cm showcommands --all misses at least one command that is in the any list, but is in the all list: cm wi, which is not documented on-line either. It is undocumented because it is considered “legacy”:
Show info about workspace selector.
gra
Usage:
cm wi [wk_path]
Options:
wk_path Path of a workspace on the machine.
Remarks:
The wi command shows the working configuration of a workspace (repository,
branch, and/or label).
Examples:
cm wi c:\mywk
I found very few on-line posts on cm wi, and the ones I found did not add much to the above:
One problem: cm wi sometimes does not list your branch at all, despite the PlasticSCM GUI showing it.
Still room for research here…
Finding more documentation
Much of the cm documentation can be found at
the documentation for [WayBack] CmdRunner: The Plastic SCM API: CmdRunner, an automation layer built on top of the command line to develop Plastic SCM plugins and features
Plastic uses an ignore.conf to specify which files and directories should be ignored. I am not sure yet about a similar file hidden_changes.conf.
There is hardly any documentation on the ignore.conf syntax, but there is documentation on the places where it can reside: in the repository itself to apply for all repository users, or on your client system in a central place for any repository, or a specific repository. These links tell more:
What I’m doing for now is converting gitignore lines manually by applying these rules. I’m using Plastic SCM 7.0.16.2346.
For exception rules that want to match only folders, decide whether to remove the rule completely or to expand the exception to both files or folders. The only case I’ve seen so far is this
# Visual Studio cache files
# files ending in .cache can be ignored
*.[Cc]ache
# but keep track of directories ending in .cache
!*.[Cc]ache/
For each line with a trailing slash, add a duplicate line without the trailing slash. This way both the folder and its contents get ignored, like Git does it. (For folders that don’t begin with a dot, it’s enough to have the line without trailing slash.)
For ranges whose purpose is to express a case-insensitive match, such as [Rr]elease, replace the range by the explicit correct case, e.g. Release. In simple cases like this it’s also possible to add both case alternatives. Plastic SCM’s rules are case sensitive.
Hm not sure I fully understands the rules when it comes to wildcards, I’m trying to ignore build output directories (Debug_VS10 and Release_VS10) so I tried using the following:
*_VS10/
That didn’t work, but this did:
*/**/*_VS10/
…
I forgot to mention that the directories has files within them.
If I add both:
*_VS10/
*_VS10/*
it seems to be working.
If I specify the directory names without wildcards, it is sufficient with only the directory rule:
Debug_VS10/
Release_VS10/
…
So, if I wanted to say “ignore everything in A except for cs files, and ignore absolutely everything including cs files in A/B”, then that’s impossible in Plastic SCM? That’s very inconvenient for users of Unreal Engine because of the way it intersperses generated and downloaded files throughout the directory structure. Git supports this sort of arrangement very easily by giving increasing priority to each line in the ignore file.
The user interface does not have any menus, and lacks consistency in user-interface flows: similar actions in various views are accomplished in different ways. This means that as a MacOS or Windows user, it has a far higher learning curve than needed. Example:
It includes these UI controls:
a two-state button (“Hide diffs”, which the Microsoft Narrator calls “Show diffs” in either state)
a two-state checkbox (“Check/Clear all”)
an “Options” button with a caption, but no glyph
a “Refresh” button on the far left with no caption, but a glyph
an “Information” button on the right, just before “Filter” with no caption, but a glyph
a “Filter” edit on the right
a “Checkin” dropdown button of which the expansion includes “Shelve” (not intuitive!):
an “Undo changes” dropdown button of which the expansion includes “undo unchanged” (not really intuitive, but understandable):
Focus is also inconsistent, leading to hot-keys not to work after switching tabs with Ctrl-Tab:
The above, together with a lot of smaller gripes (for instance no automated check for updates like most other software development tools I know) sort of made me glad am now mainly using other version control systems. But I still miss the branch explorer in those tools.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
The Wiert Corner - irregular stream of stuff 
Leave a Reply