Manually specified file version selector names when uploaded from client via Git
Problem: I upload changes as a commit range in git between a reference branch (master) and my current HEAD. I then later need to rebase my current HEAD against an updated reference branch (master) and re-upload the changes. It cannot be differentiated in the file version selector during a review which versions of the file are reference branch (master) and which are HEAD versions. Generically, client tool uploaded differences from git commit ranges automatically label all versions of files as seen in file version selector drop down, with check-in time and non-human readable git object hash (not commit hash) only. Rebasing changes against the latest version of the reference branch, or merging the latest version of the reference branch into the changes, between a first and second upload to a review causes the "before" version from the reference branch to be different during the second uploaded of files and have a newer timestamp than the "after" version of the file from the first upload. The "before" versions therefore can't be differentiated from the "after" versions in the drop down. Solution: Add optional command line argument for "addgitdiffs" that will allow user specified names to be added to the before and after versions of all files included in the commit range. Conflicting names are automatically appended with standard "(1)", "(2)", etc for a given file based on upload order. For example, if I have changes on a "work" branch that originally forked from "master" branch and changed fileA and fileB, my upload command would be ccollab addgitdiffs --before-name="master" --after-name="work" ask master...work which would upload all changes made on the work branch since it split from master by uploading fileA and fileB from the commit on the master branch right before the work branch split, and fileA and fileB from the head of the work branch (currently). The extra arguments would add labeling for all the files from master as "master" and those coming from the work branch as "work" (new). When my review continues for a while and I need to rebase my work branch against the since-updated master branch I'll need to re-upload my changes relative to the new reference point on the master branch. Running the same command as before accomplishes that but causes a problem. When the differences in fileA are viewed without this feature, what's seen in the file version selector drop down is (larger numbers with the timestamps indicate newer timestamps): "<git object hash> <commit timestamp 1>" <---- from master branch in first upload "<git object hash> <commit timestamp 2>" <---- from work branch in first upload "<git object hash> <commit timestamp 3>" <---- from master branch in second upload "<git object hash> <commit timestamp 4>" <---- from work branch in second upload With the recommended feature this list becomes much more clear: "master <git object hash> <commit timestamp 1>" <---- from master branch in first upload "work <git object hash> <commit timestamp 2>" <---- from work branch in first upload "master(1) <git object hash> <commit timestamp 3>" <---- from master branch in second upload "work(1) <git object hash> <commit timestamp 4>" <---- from work branch in second upload3.1KViews1like0CommentsMatch addgitdiffs commit hash specification in the Command-line client to git commit hash specificat
The addgitdiffs command uses Git commit hash syntax identical to the git tool itself except in one regard: specifying individual commit hashes for addgitdiffs is handled the opposite of how the git tool does it. In Git syntax the following lines are identical: git diff AAAAAAA..BBBBBBB git diff AAAAAAA BBBBBBB In the Collaborator command-line client the following lines have exactly opposite meanings: ccollab addgitdiffs ask AAAAAAA..BBBBBBB ccollab addgitdiffs ask AAAAAAA BBBBBBB This seems to be because the addgitdiffs command handles the second case as a list of individual commits, which it assumes are in reverse chronological order (newest to oldest), rather than a direct pass-thru to the git tool (oldest-first) like the first command. To resolve this, split the addgitdiffs command for specifying a list of commits into a separate command (or require extra options).3KViews0likes0CommentsCollaborator 13.2 and 13.4 cannot login in the command line if the password contains a double-quote
Any time thepassword contains a double-quote, the login command below raises an exception. Example: if the password is 123"456, then the login command must be: ccollab.exe loginhttps://collabserver.ioMatei "123""456" The Collaborator server throws an exception: Trying to login with new configurationjava.net.SocketException: Network is unreachable: connect at java.net.DualStackPlainSocketImpl.connect0(Native Method) ERROR: Executing command `ccollab login`: java.io.IOException: Network is unreachable: connect com.smartbear.collaborator.client.exceptions.CollabClientException: java.io.IOException: Network is unreachable: connect The correct answer from the server would have been: Connecting to Collaborator Enterprise v13.4.13401 Server https://collabserver.io Collaborator Enterprise client credentials invalid. Please supply a valid password. This situation was not present in version 12.4, the double-quote was accepted in the password!2KViews0likes6CommentsHow to access review files vai JSON or the CLI Client
I have a case where I need to run a 3-rd party tool in order to provide a textual diff of some binary files. Files are stored in Bitbucket and a Collaborator review is created when a pull request is made. I'd like to insert the textual diff as a file into the peer review, triggered by the Added File Trigger. In that trigger, I'd need to get all the files that were added, identify which ones were the custom binary files and then download the last two versions and send it to the 3-rd party diff tool. The result of that diff will be added as a new file into the reivew. I will potentially need to scan old reviews or reviews where the Added File Trigger failed to add the diff, and so a JSON or cli client solution would be ideal, rather than just relying upon the Added File Trigger variable substitutions. I've been unable to identify any way of getting a list of files via JSON or the CLI client, nor any JSON or CLI client commands to retrive files. Does anybody have any suggestions on how to accomplish this? Theoretically, if I had enough information, I could go to git and collect data from it, however, the files already exist on the Collaborator server, and having to download the git repository for every changeset / Added File Trigger seems excessive. Thank you1.3KViews0likes0CommentsHow to automatic raise review from SVN check in?
I am using SVN check-in for my project. Is there any scope in Collaborator "Collaborator Enterprise 11.2.11200 ©2005-2017 SmartBear Software, Inc. Version 11.2.11200.355" to automatically raisereviews after SVN check-in. Thanks. Regards Prasanna1.1KViews0likes0CommentsCodeCollaborator and Git - ClearCase addversions equivalent for Git?
Dear experts, My team is actively pursuing the command line utilization of Collaborator with Git (not GitHub or an public remote Git application). In clearcase, the branch name and revision number of a file is uploaded via the "addversions" command using the "ccollab" program. This has the wonderful feature of being able to switch between revisions and knowing which version you are on. WIth Git, there aren't really "version" as much as there are hashes for commits, which are what show up when you upload diffs or files to Collaborator. I know it is possible to upload comments to the overall review page such as: $ccollab addgitdiffs --upload-comment "$(git log -g -n 1 "03db" --)" "69451" "03db^..2fbe" that grabs info from the commit 03db and puts it on the review page. This does not contain information on the branch normally. Is there anything that can mimic the behavior of ClearCase so that the Git branch is clear and it is relatively easy to track which revision of each file is being looked at, or is this a lost cause. Thank you for any help.991Views0likes0CommentsDifferent output on website & via command-line client
I am trying to get license usage data for a server via a script. The only way I know how to do that is through the ccollab command-line client, specificallyccollabadmin wget "go?component=ErrorsAndMessages&step=AdminLicensing&page=Admin&ErrorsAndMessages_fingerPrint=861101" That output yields the correct page but the wrong data. From the command-line client:70 floating-seat licenses; currently using 0. From the web client:70 floating-seat licenses; currently using 30. Any idea why they're different? If the command-line method won't work, is there another way to get the information programmatically?979Views0likes0CommentsLog all activities of users and admins in Collaborator
In a Large enterprise there will be multiple admins. To track who has done what, Admin should be able to get the log of all users activities. Like, Disabling and Enabling review templates, Disabling and enabling users or adding users etc. In simple terms a log should be generated for every activity happens in Collaborator through all the ways. ex: GUI, API, Collab client, Thirdpart clients, Commands etc.979Views1like0CommentsChecklist - CLI
Hello, How can I check an item from checklist from Command Line? I have tried to run this command:ccollab admin review create --checklistitem-custom-field "Check_List_Title=true" ,but I have java.lang.NullPointerException. I have also tried to edit an existing review withccollab admin review edit --checklistitem-custom-field "Check_List_Title=true" , but I still have an error. Thank you!940Views0likes1Commentcollaborator client install issue (win10)
during client install the following error is encountered: Error "LoadLibrary failed with error 126: The module could not be found" This may be more of a windows library issue, but would like to determine if any knowledge sharing is available here in regards to collaborator client specifically. additional information; this was encountered during a remote desktop interaction.Solved866Views0likes1Comment