Jump to content

Search the Community

Showing results for tags 'partial workspace'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Plastic SCM
    • General
    • Installation and configuration
    • Unity 3D
    • Plastic SCM on Mac
    • Plastic SCM on Linux
    • Gluon
    • Git interop
    • Integrations
    • Community Edition
    • Branching and merging
    • Announcements
  • Plastic SCM 4.0 Beta (Closed)
  • Plastic Cloud
    • General
    • Configuration
  • SemanticMerge
    • General
    • License
    • SCM's configuration
    • Share your experience!
    • External Parsers
  • GitJungle
  • Method History for Subversion

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 3 results

  1. 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
  2. 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
  3. Hello, Our design team has recently purchase a subscription of 5 users (screenshot: https://i.imgsafe.org/eccbdd1.png). I believe it came with plastic Gluon as well. For the last year or so, we used to use an old version of Plastic with community licence. But upon installing the newest version of Plastic Gluon as well as Plastic SCM, we're having a plethora of various errors which haven't been able to troubleshoot. Our current user accounts are these: https://i.imgsafe.org/eb199c5.png with these accounts as admins: https://i.imgsafe.org/eb940a4.png 1) As we try to commit (checkin) changes from various client machines using Plastic SCM, we see an error telling us "The maximum number of licensed users has been exceeded." Screenshots: https://i.imgsafe.org/ec55484.png 2) Upon the removal of one of the accounts "Shafayat", we still see the same error. Screenshots: https://i.imgsafe.org/4689c07.png 3) Attempting to checkin from the client "musavvir" using Plastic SCM gives us the error "This operation cannot be performed in partial workspace." Screenshots: https://i.imgsafe.org/ebecd10.png 4) Attempting to checkin using Gluon from the client "musavvir" gives us the error "A deleted directory cannot contain changes after the ci operation." Screenshots: https://i.imgsafe.org/ea6209b.png 5) If we try to checkin using Gluon from the client "sadia", it gives us the error "This operation cannot be performed in standard workspaces." Screenshots: https://i.imgsafe.org/ecd218f.png We would very much appreciate if you look into these and suggest a solution or a workaround around this mess.
×