Search the Community
Showing results for tags 'partial workspace'.
Hiho. We're trying to use a workflow where users should start off with a workspace containing only parts of the repository, but can update to a full copy if they wish. I'm guessing Gluon is exactly the tool for such a scenario? However, we have some usability concerns for our scenario, which is as follows: In our scenario we have a Unity project with many (>=100) 3D models, which usually consist of the model itself (an .fbx file), and several/many texture files for each one. The problem with the textures is, it can take VERY long for Unity to import them after an Update. So the idea is to have a workspace that only shows/contains the .fbx files, to be able to get a quick overview, but if the user wants to he can download the associated textures from the repository into his workspace. However, in Gluon it seems I can "only" load/unload specific directories, not wildcards and/or filetypes or similar. As in our scenario we usually store each model in a separate directory, which has its own subdirectory "tex", containing the associated textures, the user would have to first DESELECT >=100 directories named "tex", located in each model directory. And once he decides he now needs the whole repository, he would again go through the whole hierarchy and SELECT >=100 directories named "tex" (although it seems this step could be simplified by selecting the parent, which hopefully will recursively select all files/directories which are currently unloaded?). This is of course not feasible - and would probably take even longer than just letting Plastic download all textures in the first place, and letting Unity import them... Are we missing something, is there another way/workaround/trick? For example, to use wildcards or relative paths or something like that? EDIT: Hm, we don't really use the Unity-Plastic plugin (although we always connect our projects via the plugin), as the client is so much more powerful than the plugin. But maybe when using Gluon one can use the filter/search field in Unity's "Project" tab to quickly select all "tex" directories for example, and maybe then can Gluon-load/unload these all at once? EDIT2: I just realized, this thread probably belongs in the "Gluon" section... Thanks a lot! Cheers, Wolfram
Hiho. We're trying to use a workflow where users should start off with a workspace containing only parts of the repository, but can update to a full copy if they wish. From what I found out, using Gluon is probably the way to go - although there's still a severe usability issue in our case. But I'll post that in a separate thread. However, I did a few tests to see if cloaked.conf could help us achieve what we want. But it seems it cannot, as using cloaked.conf appears to have several severe drawbacks, which prevents it from being of any use in a working environment in most cases. In our scenario we have a Unity project with many (>=100) 3D models, which usually consist of the model itself (an .fbx file), and several/many texture files for each one. The problem with the textures is, it can take VERY long for Unity to import them after an Update. So the idea is to have a workspace that only shows/contains the .fbx files, to be able to get a quick overview, but if the user wants to he can download the associated textures from the repository into his workspace. I tried to accomplish this using cloaked.conf, but any variant I tried seems unusable: - Just adding "*.jpg" to cloaked.conf will work for existing assets, BUT it will prevent any future *.jpg that is added from showing up in Pending Changes (so it can never be committed!). As I understand, the workaround is to temporarily remove the cloaked.conf entry, which makes new (and changed) files appear in the Pending Changes. However, even then it's rather complicated to have our modellers open a text editor to manually aund temporarily modify this file (or remember to do this via the right-click context menu). In the real world, this will get forgotten (which results in textures not being committed, and this missing from the repo), or the modified cloaked.conf will be accidentally be committed as well without noticing, forcing all users that update to involuntarily download all textures - which is exactly what we're trying to prevent. Or they will forget they have a locally modified cloaked.conf - which also forces a download of all previously cloaked textures on the next update. With Unity, having the *.meta-Files in sync with the main assets is also vital. In the real world, people will forget to also add/remove the *.meta-Files from cloak, leading to problems that are difficult to trace, and which can cause dangerous inconsistencies (=multiple IDs for the same object, lost references, ...) - Not adding a catch-all "*.jpg" to cloaked.conf, but instead commit the textures normally, and only then add them explicitly (or their directory, which is usually unique per model and contains all relevant textures) seems another way to go. However, again, people will - per definition - forget they have to modify cloaked.conf as well after changing/adding a model. Also, this approach seems to require TWO commits per change: first, commit the model with all textures, THEN modify cloaked.conf (as the new textures cannot be committed if they are already covered by cloaked.conf). - More importantly, it seems impossible to locally update or modify any assets that are listed in cloaked.conf - at all. I couldn't even get the "cm.exe upd --cloaked" workaround to do that. And here, even the "locally modified cloaked.conf" is not working - even when removing these files from cloaked.conf, they are still invisible for updates. There were additional problems with the cloaked.conf workflow, as for example that suddenly the built-in diff was unable to correctly display certain differences, even when diffing existing changesets in the branch explorer. Are we missing something? Is there a workflow using cloaked.conf where we can achieve what we want? And what use is the claoking option if those files can never, ever, be updated again? Ideally, a global catch-all should prevent downloading/updating the specified files, but should of course enable us to ADD more files of that type to the repository, and FORCE an update of any repository changes to get the local workspace...well, up-to-date. EDIT: The docs at https://www.plasticscm.com/documentation/gui/plastic-scm-version-control-gui-guide.shtml#ColumnsintheItemsView say "An Update command bypasses the item (unless you explicitly selected it when issuing the update)." How/where can these "explicitly selected"? I was not able to do that. And as mentioned above, the CLI-workaround "cm.exe upd --cloaked myDirectory" doesn't work (as in, it doesn't do anything different than issueing that command without the "--cloaked" parameter). Thanks a lot! Cheers, Wolfram