According to the Unity tutorial, the only folders that should be in version control are Assets and ProjectSettings. The rest of the assets and files that make a project are supposed to be generated by Unity. As a test I tried to open a project directory that only contained these folders. It loaded the project, it just would not run because some dependencies were missing.
https://unity3d.com/learn/tutorials/topics/production/mastering-unity-project-folder-structure-version-control-systems
It seems that critical assets imported from the Asset Store are not contained in either of these folders, nor are they automatically generated when a project is opened, they must be installed/imported manually the first time. My goal with my version control is to be able to do a fresh pull from git and be able to run the project off the bat.
The missing assets seem to be located in /Library/PackageCache/. Copying the folder to the test environment doesn't work, as this folder is cleared the first time Unity is run. What files do I need to keep to make this work?
According to the Unity manual, you only need to include 3 folders into your version control system:
"When checking the project into a version control system, you should add the Assets, Packages and the ProjectSettings directories to the system."
The easiest way of setting up version control for Unity it to use Unity's own version control called Plastic SCM. It has two modes: Programmer mode and artist mode. I recommend Artist mode (Called Plastic Gluon) for ease of use especially if you are the only person working on the project. In both modes, Plastic SCM will automatically includes what is necessary and exclude the unnecessary files.
Related
I am working with Vuforia in Unity 2019.2.5f1 and building the project for Android. I have some Vuforia related files in the Packages section which I have edited to make some part of the project work. Everything works fine and the changes made in that file are visible when I run the project in my device directly by using the Build and Run option.
However, I also want to do some additional stuff in the project using Android Studio. For that, I export the project by checking the Export Project option in Build settings. The exporting is done fine, but the Package file in which I made some changes, is reset to its original data. The exported project (which is an Android Studio project) does not reflect the changes as well. Other files present in Assets section work fine and changes are visible, but not the files present in the Packages section.
Basically, I have a file in the Packages section which I need to change, but the changes are not reflected in the exported project. But, are visible when I run the project directly from Unity in my device. I want those files not to reset. I need some guidance on how to achieve this.
I am not very experienced in Unity. Any help in this regard is appreciated.
Thanks
In short: Do not edit anything in the Packages .. they get recompiled/imported automatically and in simple words: You can't prevent it.
What you can do however is copy the entire according folder from the Library over into the Assets and thereby make them local files you can then edit. See Embedded Dependencies
As mentioned in this thread by Unity Technologies (22.05.2019)
Yes, currently the way to develop a package is to copy/move it to your project's Packages folder.
Also see Copying a Unity package from the cache for further information.
In general no changes should be necessary to a Package directly. Maybe you should rather implement your own script and only copy the original content and then rather make your changes their?
I have recently started learning VR on udacity, and when I use unity, no scripts show up in the inspector. When I use 5.6.1p2, I get this message.
Here is the console tab
I recently installed a beta version of unity, as referred to by a mentor, and there is no longer an error message, but the scripts simply do not appear
Problem resolved:
After putting course assets into a new folder, and extracting them, all dependencies were accessible within unity. Library was rebuilt with all required dependencies, and project is completed and working.
To open the project, I opened unity first, and used the open project button to select the folder including the assets, library, and temp folders. When I opened through the assets folder, the library wasn't complete, therefor not all components and dependencies were accessible.
Sometimes Unity not show folders with corrupted meta file. just delete meta file with this folder name
We want to share an eclipse Qt project via an SVN repository.
Of course we need to share the .pro file of Qt to be able to build the project.
The problem is, that without the project files you can not handle the project in eclipse but we cannot use the same as they contain local references.
Also it would be nice to use the Eclipse SVN plugin to manage this.
I already tried to check out the project and create a Qt project on Checkout but this overwrites the checked-out project file.
Any suggestion would be appreciated.
These are some lines from the .cproject file that are autogenerated, so I can not change the absolute paths:
<storageModule moduleId="org.eclipse.cdt.core.pathentry">
<pathentry base-path="/usr/include/qt4" include="" kind="inc" path="" system="true"/>
<pathentry base-path="/usr/include/qt4" include="QtWebKit" kind="inc" path="" system="true"/>
...
There are 2 rules for Subversion (independent of Eclipse, should be the same all the time):
If the tool will regenerate a file, and you don't have to change it:
==> don't check it in your version management (may it Subversion, Git, CVS, ...).
If the file contains parts that are manually changed by a user
==> it should be checked into version management.
If you have the second case (not clear from your question), you should try to change the paths to be relative, so that others could use your project at the same location.
If you cannot change that, stick to the location in the file system. Every developer has to use an identical setup.
If you have to support different operating systems, and the files generated by the tooling are not compliant (shame on the tool makers), you should hold templates for all operating systems in your version management, and should initially (manually) make a copy, depending on the operating system you are working in.
If you have to change that file for some purpose, you have to change the templates as well and should remember that all developers have to make a new copy after that.
Sorry, I don't know Qt and have never developed in a C-environment on different platforms, so my tips are pretty vague.
Finally I found following solution:
No .cproject .project file in SVN!
Import the code files from SVN (also the .pro file for Qt)
Eclipse will ask you to create a project, so create a Qt Project with the same name (or some else, but you will then have to delete the files)
When the project was created, revert it (right MB on the Project in Project Explorer -> Team -> Revert) to the state of the repo checkout
Done, now you can work with the project
This question was close to mine, but not quite.
I have a Windows desktop and a MacBook Pro. I'd like to be able to keep my Eclipse workspace in my Dropbox folder. The problem is that many project settings change between platforms: references to JREs, JDKs, and other libs.
Every discussion I've seen of this problem seems to suggest taking advantage of the source control system's ignore functionality, so that such-and-such file remains local-only and thus able to remain platform-specific. But when you're working with a real single shared folder, that class of solution doesn't apply.
Have you had luck working with a Java Eclipse project living in a single folder shared over the network, cross-platform?
I have my Eclipse workspace inside Dropbox with all my project folders within, but use the new-ish "Selective Sync" feature of Dropbox to make sure that the .metadata folder is not synced.
This means my Mac and Windows machines have their own .metadata folders but the project folders remain in sync.
Seems to be working so far...
Use source control with individual workspaces. By doing it this way you lose the capability of two developers making changes to the same file. You also run a higher risk of people stepping on each other. With Subversion (or others) source control is free and gives you traceability.
Perhaps the way to have less problems is just to share the source folder, neither workspace settings nor bin folder.
Just put your source folder in Dropbox.
Create the project on site1 and then:
Right click over the project, choose properties
--> Java Build path --> Source tab
--> Link source button
Then create a link to your source folder in Dropbox and assign it a name (e.g. src2)
Make the same for site2.
All your source files must be in your share source folder in Dropbox.
Of course you must configure on each site the settings like libraries and other stuff but this task is less frequently and perhaps desirable because you have two different environments.
For anyone else having trouble getting this to work, try File->Import->General->File System. Be sure to select Create links in workspace from the Advanced options. Seems like the cleaner solution and you can keep using your usual workspace.
We normally use Eclipse for a particular Java project, but recently I imported the project into NetBeans to use its dialog building features.
Since I'll probably come back to this, I wanted to store the NetBeans project files into version control. However, I don't want to commit files that are "mine" versus "project", i.e., files with my own settings that would conflict with another user's.
NetBeans created the following structure in the top-level project area:
nbbuild
nb-build.xml
nbproject
<various files>
configs
private
Clearly nbbuild is build output, so that won't go in. The nb-build.xml file seems likely, as does most of nbproject. However, nbproject/private suggests it's "mine". Peeking at "configs", it's not clear to me if that's mine or project...
Anyone have some guidelines?
The NetBeans knowledge base article on project files & version control discusses the NetBeans project files, with loose advice about which files are project specific (i.e. can be shared via version control), and which are user specific.
Here is the section on version control:
If the project is checked out of a version control system, the build (or nbbuild), dist (or nbdist), and the nbproject/private folders should not be checked into that version control system.
If the project is under the CVS, Subversion, or Mercurial version control systems, the appropriate "ignore" files are created or updated for these directories when the project is imported.
Though nbproject/private should be ignored, nbproject should be checked into the version control system. nbproject contains project metadata that enables other users to open the project in NetBeans without having to import the project first.
It turns out that both Thomas & Petercardona are correct, in a way. NetBeans recommends that you only import source code and/or documentation. Oh and the nbproject folder but not the *nbproject/private** folders.
From the NetBeans Knowledge Base article on importing Eclipse projects:
Version Control Considerations
If the project is checked out of a
version control system, the build (or
nbbuild), dist (or nbdist), and the
nbproject/private folders should not be checked into that version control
system.
If the project is under the CVS,
Subversion, or Mercurial version
control systems, the appropriate
"ignore" files are created or updated
for these directories when the project
is imported.
Though nbproject/private should be
ignored, nbproject should be checked
into the version control system.
nbproject contains project metadata that enables others users to open the
project in NetBeans without having to
import the project first.
None.
Only source files, build scripts, and documentation that is not automatically generated (e.g. - the output of tools such as JavaDoc and Doxygen) should be checked into a repository. Things like project files, binaries, and generated documentation should not be checked in.
The reason is two-fold. First, you don't want to overwrite another developer's project settings with your own. Second, other developers might not be using the same IDE as you (or even an IDE at all), so don't give them any more than they need to build (the project or its associated documentation) or run the project.
As tested with Netbeans 6.8, only the project.xml, configurations.xml and the main makefile (the customisable one in the parent dir of the 'nbproject' dir, with pre/post target definitions) must be distributed via the repository. All other files will be automatically (re)generated by Netbeans (Makefile-impl.ml, Makefile-variables.ml, all the Makefile-$CONF, Package-$CONF.bash). The 'private' dir should also be ignored, obviously.
You can check also
https://github.com/github/gitignore/blob/master/Global/NetBeans.gitignore
This open source project contains
A collection of useful .gitignore templates
Toptal has a useful tool for developers wanting to find out what should go on a .gitignore file.
https://www.toptal.com/developers/gitignore
For netbeans, just search Netbeans and it should return a template something like
**/nbproject/private/
**/nbproject/Makefile-*.mk
**/nbproject/Package-*.bash build/
nbbuild/
dist/
nbdist/
.nb-gradle/
Copying and pasting this into a .ignore file on your project's directory should solve your problem.