CadmusLabs

We don't use unity integration plugin. ignore.conf is in the repo. plastic-global-config - I don't know what is that.

I use this one, though some users may have a bit older one. Yes we use Unity;

Hello! After this mid year updates (9.xx something) ignore.conf started to change in users workspaces randomly - it adds some ignores, people don't notice this change in change set, commit into cloud and break project for everyone. What happened, how can I prevent it? I happens ofted during switching between branches, it just changes for some reason.

Hello! We have a pretty big project and sometimes people edit same file at the same time - Unity scenes in this case. Unity has merge tool for it but it is not effective with the size and complexity of scenes we have. So what I want to do is to prevent .unity files from merging - users should be able only to choose keeping source or destination version. How can I do that? Thank you. (Locking files still does not work for replication with local repos, right?)

Alright, I will try to master it. Overall - thank you a lot.

I need to study it, might be good but maybe not for our workflow. I merge manually because it's part of review process and going through certain checklist - are files name correctly, are they in correct places etc.

Yeah that's what I wanted to ask about too. Is there any expectations to have it not only in Gluon? Subtractive merge is very handy, except for cases when you only need to revert part of changeset. For us it is very common. But we don't want to have two clients because it takes time to teach people even one

Why? it's commonly used. Yes sources are rarely deleted, but other resources like icons or binary files are often removed and then need to be restored. It's not bad but does not scale for a bigger production. We only have about 10 active users and being an integrator of tasks is a mess without a search. I mostly don't rely on branch explorer at all because it's a cobweb. This is like one week or something. Yes it's pretty handy. You should make it pretty standart cause it makes sense. Workflow'd be like Check JIRA for a task which you are supposed to integrate JIRA Id is equal to the branch name. So if task is something like ANIM-383 I look for CurrentDevVersion_Branch/ANIM-383 - I search it in Branch Explorer or Changesets list. Again both those views have search fields but those search fields need to be stellar and have perfect usability - also branch navigator need to postition me to needed changeset/branch and highlight it - sometimes it takes couple of tries just to figure out by eyes where this damned commit is. When I found the branch I often browse its content to figure out if it looks like the task which was requested - there is human factor after all. If it is ok I right click on the branch and use Merge from this branch (or changeset) to... - Why I do this? Well I'm already positioned on this particural task in branch view, I don't want to scroll back to current "main" branch. Also my workspace itself can be on any other random branch - I don't want to switch because in cloud based workspace I will need to download all the changes and it is relatively slow. I don't want to switch to main branch cause again it will take time. When changes are applied and downloaded I resolve conflicts, diff changes for quick review etc and then push it to main branch. All that without doing any switches at all - I can be anywhere in the history for whatever reasons I have during development. For replication approach it is not much more different except ofcourse that I will need to replicate both the main branch and branch with the task I'm integrating before switching to branch view. Replication window actually has same serching problems as the one I mentioned in the original post- to download it you need first to find it - though in there you can exclude branches which is handy.

Why reverting does not work for deleted files? It works ok for files which are changed but if it is removed I need mumbo jumbo. It says - downloading the revision but pending changes are empty;

Hello! I have seen there is no tool to cut history on the cloud, which is ok for now, though needed in future. But what is really inconvinient that I need to browse through entire project branches history. We have like 2000+ branches cause we have branchs per task and per game version and users have personal branches etc. I really don't need to see this alpha0.6 - I will never ever merge to or from it. But still every time I do Merge from or Merge from this to... in Branch Explorer I need to filter through this obsolete stuff. If there any tools to cut it out? Basically I need to filter all branches older than certain date or all branches which are not the current dev branch or its descendants. Sometimes I might need to turn it off to browse what happened in previous dev version but this is rare. I don't need it often. This filter field is so 2003. It does not save my previous selections, it only sorts alphabetically, it does not try to propose me relevant branches. Really one of the worst panes in entire software cause it looks like a field for Hello World project where you don't have big data. I actually a bit pissed of that usability on windows is worse than on mac client overall. Maybe add filterng by tag or parent branch, maybe add adding to favorites maybe something else, this is weak right now - text search only. Looking for work arounds in curent client and huge improments in future. This pane is part of Branch Explorer ecosystem which is one of the most used parts of software and need to be stellar. Cheers.

- Distributed workflow: Your workspace is pointing to a local repo and then you sync (push/pull) against the central repo. You can use a sync view and this way only sync/replicate the desired branches. You can also use the" nodata" replicas to perform lighter clones. Yeah we use this one. Thank you calbzam, we will try nodata replicas.

Hello, thank you! Remove rules looks like something that may be helpful, but again looks like you need to download everything before applying this rule... so same problem as with cloaking.

Hello! We are using plastic at Dark Crystal Games for almost two years now and are pretty happy. But I wanted to improve couple of things for my team going into 2020 and I need some advises on that. TLDR: How to use cloaking or other config to prevent certain folders from downloading from the cloud into the local repo? ---- Full version First of all we will need some sort of overview how we use plastic. We use cloud edition hosted by, well, Codice Software of course We are using fully distributed approach, I assume, when everyone have a branch and we push it all into a cloud. Half of the team uses replication method (so they have local repo) and half of the team only has workspace copy and works with a cloud directly. We create all sorts of things - code, scripts, levels (unity), binary 3d art files (max etc). So now we face a problem that our working copy is above 25 GB of content (not counting history) while we still do not sync all the file types with plastic. We don't sync sound and music files and also source files of 3d models and textures (those can weight hundreds of megabytes each). We need to use other tools like Dropbox and Mega to sync those sources (we easily have 400 GB of licenced sound assets and only few hundred of megabites of those are used to produce "designed" sfxs which are actually used in the game). We want to sync EVERYTHING with plastic and have a full history of it. But then we face the issue that the user must download 500 GB project which is a bit questionable, right? The structure of the project is something like this UnityProject - this is actuall game (you will get a game build if you build this folder), it only contains final artwork, like .png and .fbx, scripts, levels etc - things the game is made from FMODProject - this is a project for sound middleware of FMOD. It consists from events (text mostly) and "designed" pieces of sound and music. Those things are built in banks and banks are copied into the UnityProject Sound - this is our entire Sound library and it is HUGE Art - this is our entire Art drive which contans PSD and MAX files and it is HUGE too. So normall user only actually needs UnityProject if he wants let's say do level design and never integrates new assets. While ART folder is only needed to artists and those who integrate MAX files in the form of final FBXs and add those into the game. And there is only one person who works with sound. But at the moment every user is forced to download EVERYTHING. ---- This sounds like something you can solve by cloaking certain repositories or file types, but unfortunetely it does not. Cloaking only affects Update command and to run update when you use replication approach you first need to download a branch (so those 450 GB) and then you will cloack it locally. This does not solve the problem... Am I missing something? Perforce has a system for this problem (I think it is called _views_ but correct me if I'm wrong) Thanks