Implement sync of GitHub pull request reviewers and Collaborator reviewers
Submitted on behalf of Debdas Mondal (HSBC). GitHub pull requests may have reviewers assigned to them. It should be possible to synchronize the list of pull request reviewers and the list of a linked Collaborator review's participants.
Renamed/moved file shown in Review Materials
Indicate either in the Review Materials overview, or in the file differences view when a file has been moved or renamed. This information is tracked by a number of Version Control systems, and clearly indicated when examining the differences between commits/check-ins. Currently a moved or renamed file will show up as completely removed from the old location (all contents removed) and completely added to the new location (all contents added). If changes were also made within the file in the same range of commits/check-ins under review, they can't be differentiated. As a possible implementation, both the old and new file names in the Review Materials overview could link to the same file differences view where the before and after file names are listed as different at the top of the window (where there's currently only one center-aligned file name as of 11.0.11000).Tracked Branch regex/globbing for Remote Repository Integration
When configuring GitHub or GitLab in Remote System Integration, a branch(es) to track must be entered if "master" isn't the only branch you want to track. This controls which branches targeted for a merge as part of a pull/merge request will automatically create Collaborator reviews. In a pretty common git workflow, release branches are created for use as hardening/stable branches in addition to the mainline branch. If automatic Collaborator reviews based on pull/merge requests against these release/stability branches are also desired, they have to be included in the Remote System Integration list for the repo they're in. In our use case, we create a branch "rel_v##.##" for our hardening and release candidates as we're getting close to release. This branch is named and numbered related to the specific release number. That means we currently need to modify the Remote System Integration for our repositories every time we approach release. If glob or regex patterns could be specified for the Remote System Integration branches to track (at least for GitHub and GitLab), it would resolve the problem of constantly having to modify the Remote System Integration setting for a number or repos. As long as a consistent naming convention was used for branches, those branches that should be tracked could be specified once as a pattern and then never need to be updated again.Separate Remote Repository Integration accounts from repositories themselves
When integrating with GitHub and GitLab, a separate Remote System Integration must be added for each project/repository. However GitHub and GitLab operate with a single account list per installation instance, and then a member filter per project/repository. This results in users needing to repeat identical username information for every repository/project the Collaborator instance is integrated with. Instead, the Remote Repository Integration could separate systems from repositories/projects. A "System" would be a configurable list that would present to the Users as needing their username to match. Repositories/Projects would look like what is currently provided, for Remote Repository Integration, but would have a mandatory "System" drop down to select which of the configured "System"s the repository is associated with. If a specific repository needs slightly different settings from the rest of the repositories in it's existing "System", a new "System" could be added with those variations and selected as the associated "System" for that one repository's configuration. In most cases, a number of repositories are hosted in the same GitHub or GitLab instance. When Collaborator is used as the primary review tool, it's likely many or all of the repositories will be integrated with Collaborator under only a few different credential settings (depending on how many different GitLab and/or GitHub instances exist). In our current use case, we have almost 40 repositories hosted on only two GitLab instances. That means when we complete our integration, each user will have to enter one of only two different usernames almost 40 times. Even though we have Single Sign On via Active Directory being used for Collaborator and both GitLab instances, GitLab has decided usernames are the human readable version of a user's name as listed in their profile, so no automatic matching can easily occur (all GitLab's fault).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 uploadMatch 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).File permissions changes included in file reviews
File permissions can be a critical factor in files, and many Version Control systems allow creation of commits/check-ins that consist solely of file permissions changes. Request: Add the file permissions to the file differences view so they can be seen. One possible implementation might be to show the permissions settings next to the file name in the file difference view for the before and after files selected, and highlight differences.
Collaborator client/Visual Studio addin and admin rights
Hi, We are using Collaborator 10.0 and Visual Studio addin with VS 2015. For some reason we are experiencing problems using the client GUI and VS addin if we don't run them with administrator rights. Without admin rights, the client GUI starts but the Add Changes/Shelvesets/Changesets buttons don't do anything. In Visual Studio, the Collaborator pane shows up but doesn't show any reviews and the Add files to review and New review from changes buttons are dead. When we start the client or Visual Studio as administrator, we have no problems. Is it a feature that admin rights are required or should they work also without them? Any advice to fix this would be nice. Thanks a lot, - Dukeman
There is no git option in Windows Client 8.5.8501
We have a corporate installation of Code Collaborator. The server version is 8.5.8501. I have downloaded and installed the Windows Client version 8.5.8501. When I try to add an SCM configuration there is no git option. I see AccuRev, CMVC, CVS and ClearCase. If I select the folder with the git repository and let it auto detect it informs me that it doesn't know the type of version control. For reference, I have Cygwin git installed as well as Windows git. Windows git is on the system PATH. What am I missing?Add multiple pull requests to "Remote System Links"
Currently a pull request from Bitbucket can only be added to the Remote System Links section automatically when the pull request is created, and there isn't a way to add a link to a pull request manually. Is it possible to make an update that allows linking of more than one pull request in a single review? In the case of making small related changes across multiple repositories, it would be very beneficial to be able to include more than one pull request in a single review, to allow those changes to be reviewed as a set.
