I wanted to check out the inner workings of the Spectator View feature, but I got stuck.
Checking out the Repo, Unity complains about missing the HololensForCV.dll. I didn't get very far.
I found the Microsoft HoloLensForCV repository, but could not compile it. I'm not even sure, if it did, that it will spit out the desired dll.
How do I get the branch to work?
Update:
We have migrated to a new repository with samples and better documentation, please take a look here: https://github.com/microsoft/MixedReality-SpectatorView.
==================================================
Could you please try checking out this branch:
https://github.com/microsoft/MixedRealityToolkit-Unity/tree/prerelease/2019.build.spectatorView
We have documentation for SpectatorView specifically here:
https://github.com/microsoft/MixedRealityToolkit-Unity/blob/prerelease/2019.build.spectatorView/Assets/MixedRealityToolkit.Extensions/SpectatorView/SpectatorView.md
Please give it a try, and let me know if that helped.
The feature/spectatorView branch in the Microsoft MixedRealityToolkit-Unity repo no longer has any scripts with dependencies on the dlls built out of HoloLensForCV. It may be worth checking your commit log to see if it matches with the current commit history for the feature/spectatorView.
FWIW, the main feature/spectatorView branch is undergoing a lot of refactoring/breaking changes. We forked the prerelease/2019.build.spectatorView branch so that folks could start looking at ASA localization for spectator view without having to be broken by rapid development underway in the feature branch. This prerelease only supports ASA localization for an android and HoloLens (1 or 2) device. ArUco marker and QR code based localization is in progress but not yet supported.
Related
I am trying to create a branch linked from an issue on GitLab. The option to create a branch from the issue however is missing on this particular project. I have an access level of Maintainer on this project.
The current project I'm working on:
I have checked the other project I made a few months back on which I have exactly the same access level, the option that I'm looking for is there.
My previous project (This is a different project btw, not the source of the fork)
The difference being is that the current project I am working on is a forked version of the old repo so I could keep historical branches from the previous version of the project. I also imported the issues from the previous repo to the new one. I tried to create a new test issue but I still can't see the menu.
It seems like I configured something wrong, could you please help me identify why I cannot access this menu? Any help would be appreciated.
Thanks!
After some digging, I found that this may be a current known issue on GitLab. It only happens on forked projects similar to #VonC's answer. However it doesn't show how to resolve the issue.
To resolve the issue you have to remove the project's fork relationship found on the Settings > General > Advance. If you forked the repo from another project, you should see the Remove fork relationship button there. This essentially removes the fork relationship of the project from the original repository. Once done, the Create merge request should pop-up immediately upon refreshing the page. Do note you need an Owner access to see the Remove fork relationship option.
For more details, please refer to this issue and this solution was from here.
Check first if this is similar to issue 39778 which refers to issue
I disable the button for projects which are forked.
The context in when it references (from a fork) issue from the original project.
No "Create merge request" in that case.
Given that action's versions derive from their repo's tags.
Can one change an already published version by moving the tag to another commit?
If so, it's a serious security problem.. but I can't find any source to reassure me.
Anyway, it is always possible to use commit id instead of version:)
Yes, that's possible. When a tag is moved to point to a different commit, the corresponding release becomes a draft and it disappears from the Marketplace, but it can be published again.
Notice that an action doesn't need to be published on the marketplace to be used anyway.
Moving tags is actually the official recommendation for major versions and it has been debated; that discussion mentions that versioning will improve when moving to using the GitHub Package Registry for Actions, but that hasn't happened yet and the GitHub roadmap doesn't mention it, as far as I can tell.
I tried to configure GitLab integration with Bugzilla but without success. Can somebody provide an example of:
Project url (e.g. http://bugzilla/describecomponents.cgi?product=MY_PROD&component=MY_COMP)
Issues url (e.g. http://bugzilla/buglist.cgi?id=:id)
New issue url (http://bugzilla/enter_bug.cgi?product=MY_PROD&component=MY_COMP)?
I tried to provide that, but I cannot see any changes in neither GitLab nor Bugzilla.
How references in commit should look like? GitLab documentation states in one place that it should be CODE-123, where code is some unknown tracker identifier, while in another place they state it should be #123.
What functionality should I expect? Will it just provide a reference from commit to issue, or will it also add a reference to Bugzilla and maybe resolve/assign bugs?
I have an app that I have been working on and I did a bunch of changes and then realized later I should have been adding versioning to the Core Data model. So I'm trying to go back and do that now.
Basic information:
I think everything I've done would fall under the lightweight migration feature.
I'm using git
I already have the app in user's hands
My question is: what is the easiest way to do this?
Since I'm using git, could I simply checkout the data model from when I submitted it to apple, create a new version for it, and add my changes? My main fear with this idea is that my project.pbxproj file would be incorrect. Would this an issue? Is there a way to get around this?
IF I could do this, would I need to recreate my class files or would that be ok (assuming I get it back to being identical to what I currently have).
IF I CAN'T do this, then what can I do? If its a matter of starting from the last version I pushed to Apple and applying changes I guess I should look into doing it with git rebase, right?
This has nothing to do with git.
You need to create a new version of your app, provide the new data model, set it for lightweight migration and then release it as an update. Core Data will basically assume that any model without version info is version zero and attempt a migration to the new version.
When the user downloads the update, the automatic migration will trigger the first time the app runs.
Creating a new version means nothing more than changing the version number in the project info. When submitted, that will trigger the upgrade and the migration.
I am trying to understand what perforce “jobs” provide over an external bug tracking system and just putting the bug ID in the check-in comment.
I was hoping that "job" could help with How do I see if a branch contains a bug fix in Perforce?
Nothing. Take it from someone who endured years of aggravation working with the Perforce/FogBugz integration mechanisms (the latest being the Perforce Defect Tracking Gateway which uses Perforce jobs as part of the integration). They provide very little return on a significant investment in time setting them up and then trying to figure what went wrong when they stop working (which is often).
I now do just what you suggest. I simply put the FogBugz case number in the Perforce check-in comment, then add that Perforce changelist number to the FogBugz case upon resolving it. As simple and reliable as it gets.
We put the issue ID in the comment but also have a Perforce trigger that updates the issue database (JIRA) with the changelist number. During the next build the automated build process also updates the issue with the actual build number.
A very nice part of this implantation is that the trigger gives an error if the issue is not marked as in progress or the developer doing the check-in is not working on the issue. Therefore it is uncommon for a miss-typed issues ID number to get past the checks.
As a bugtracker, Perforce jobs are somewhat basic. They can be created and modified with the P4V GUI client or using p4 job and p4 jobs on the command line.
The idea is for them to serve as a link (a connector as Perforce calls it or an interface as a developer might look at it) to a third party issue management system and basically provide the information which changelists were committed for which issue. The issue management system can then tap into this information using the Perforce Defect Tracking Gateway (PDF documentation here) and generate bugfix charts or statistics for management or whatever.
We are using this with Jira in both directions with some success. The basics worked pretty much straight out of the box, more advanced use cases (such as e.g. which bugs were fixes in which release ?) or integration with other bugtrackers may require modification of the Perforce job model.
One of the advantages over tracking changelist and issue numbers using commit comments is that you can select the job/issue from a dropdown box when you commit a changelist using P4V.
In practice, developers tend to forget to add the job information when they commit a changelist. This can be enforced using Perforce triggers.