Source Control

[Geminior]

This a question rather than an issue, so if this is better posted in forum or other, let me know.

So we have all the source located in packages under the UnityPackages folder, so we can easily map these to their respective source control repository.

However ProjectSettings reside for each project under the UnityProjects folder, so if we want to source control those it seems we have to have a separate source repository for them?

Of course one alternative would be to have a single repository for the projeny solution (the root holding the UnityPackages and UnityProjects), however that is not ideal.

Is there a way to have multiple projeny solutions know of each other, so that a project in one solution can make use of packages in another? If so that would make one repository per projeny solution more viable.

[svermeulen]

No it's fine to create issues for questions

I've always gone the route of having one repository that contains all the UnityProjects and all the UnityPackages. If you have each package in its own source control, then you can't reliably traverse the history of your project, since you have to remember which versions you had of each package. Unless you're using something like git sub-modules - in which case I can kind of see the appeal of a system like that. But even that approach has problems, because you would get into issues where each package might depend on other packages, and you would have to remember which versions of other packages each package depends on. This is a problem already solved by package managers like NuGet / Bower / NPM and my hope was that eventually Projeny could just integrate with those as outlined here. For example, as I say in that issue, Projeny could maybe integrate with something like NPM via an NPM plugin, then each package could be stored in its own git repo, and could reference other packages the standard NPM way using a package.json file. I'm open to ideas here but in my mind this seems like it could work. As I say though, at our company we've been happy to just have the entire projeny "solution" (by the way I like that term!) in one repo for now.

You are correct that you will want to source control the ProjectSettings folder. Projeny will try and detect your source control (right now it only detects Git and SVN) and then will set up ignore files in the UnityProjects directory. This should result in the ProjectSettings folders being saved to source control and also the ProjenyProject.yaml file.

A couple things I want to mention that relate to this question:

• You can put ProjectSettings folders wherever you want, and you can also re-use the same ProjectSettings across however many projects you want. Then in your ProjenyProject.yaml you can indicate which ProjectSettings folder to use. See this section for details.
• You can also have multiple UnityPackages folders, and store them wherever you want. For an example, see the UnityProjects/ProjenyProject.yaml file in the samples zip. This file will be automatically used by all unity projects, and contains the list of folders to pull packages from. This could be used to have multiple projeny solutions know about each other.

[Geminior]

Ok I see thanks for the prompt answer and clarification. So both options are available, one big solution or multiple solutions with some depending on packages defined in others, that's excellent.

Just to explain the reason for my question a bit more. We have a number of packages, some of which can exist in the same repository but some which cannot (or which we would rather not have there). Our path finder and its extensions can be in one solution no problem, but then we have other projects (Games and game templates) which make use of e.g. the path finder, but really need to live in their own source repository.

You are right of course that simply sharing the main path finder project would mean that any changes made to that would apply to all those to which it is shared, which would be problematic once a release is made as you loose control of which package was used in which release, exactly as you say.

But post first release, it can be very helpful to be able to have these dynamic references set, so that we don't have to copy over the path finder package to the game project every time we make a change to the path finder (all of which we are currently interested in including). Once ready for release we would copy it over to lock it in to a certain version.

But it seems all of this should be perfectly possible already, so I will go ahead and give setting it up a go.