Jump to content

David Cañadas

Members
  • Content Count

    9
  • Joined

  • Last visited

Community Reputation

0 Neutral

About David Cañadas

  • Rank
    Newbie
  1. Sure. Some stuff renamed just for confidentiality purposes. hidden_changes.conf ignore.conf
  2. Here you have it. Yes, calculations speeded up without hidden/ignored files/patterns; from 15-30 to about 5-7 seconds. Please find the corresponding logs attached. plastic.debug.log.20201210.txt plastic.relevant.log.20201210.txt
  3. Edited The problem is happening to more than one user. They followed the instructions here with no noticeable improvement: http://blog.plasticscm.com/2018/05/debugging-pending-changes-view-performance.html The logs for the particular user that raised the request: 2020-11-27 10:58:12,228 <OMITTED> DEBUG WorkspaceStatus: DiskChangesSearcher - -------ProcessChanges:-------- 2020-11-27 10:58:12,228 <OMITTED> DEBUG WorkspaceStatus: DiskChangesSearcher - timerGetMountPoint 30 ms, 223988 times 2020-11-27 10:58:12,228 <OMITTED> DEBUG WorkspaceStatus: DiskChangesSearcher - timerProcessChange 62 ms, 223988 times 2020-11-27 10:58:12,228 <OMITTED> DEBUG WorkspaceStatus: DiskChangesSearcher - timerIsBinaryPath 0 ms, 0 times 2020-11-27 10:58:12,228 <OMITTED> DEBUG WorkspaceStatus: DiskChangesSearcher - timerIsBinaryTypePredictor 0 ms, 0 times 2020-11-27 10:58:12,228 <OMITTED> DEBUG WorkspaceStatus: DiskChangesSearcher - timerGetChangeTypes 295 ms, 223988 times 2020-11-27 10:58:12,229 <OMITTED> DEBUG WorkspaceStatus: DiskChangesSearcher - timerGetIgnoredTypes 16 ms, 2926 times 2020-11-27 10:58:12,229 <OMITTED> DEBUG WorkspaceStatus: DiskChangesSearcher - timerGetCloakedTypes 32 ms, 223988 times 2020-11-27 10:58:12,229 <OMITTED> DEBUG WorkspaceStatus: DiskChangesSearcher - timerCheckChanged 63 ms, 196851 times 2020-11-27 10:58:12,229 <OMITTED> DEBUG WorkspaceStatus: DiskChangesSearcher - timerGetHiddenTypes 0 ms, 15 times 2020-11-27 10:58:12,229 <OMITTED> DEBUG WorkspaceStatus: DiskChangesSearcher - timerNeedToProcessChildren 47 ms, 223988 times 2020-11-27 10:58:12,229 <OMITTED> DEBUG WorkspaceStatus: DiskChangesSearcher - timerGetFsNodes 14284 ms, 24211 times 2020-11-27 10:58:12,229 <OMITTED> DEBUG WorkspaceStatus: DiskChangesSearcher - Get changes total time: 15078 Our disk drives are: WD Black SN750 NVMe 2 SSD WDS (where system and Plastic SCM software resides); and Adata XPG GAMMIX S11 Pro (where we locate our workspaces).
  4. I am so sorry but I don't understand what you mean with "options marked with *". In my Pending changes/Options window there are no options marked with *.
  5. Hello, We've started to experience long times waiting the "Pending changes" tab to update. Even disabling the auto-refresh feature, it tooks from 15 to 30 seconds to update, no matter how many changes we have. Other options such checking timestamps then hashes, or modifying the move detection settings didn't improve the update time. I was wondering whether there is a way to accelerate such updates in some manner, or if you have any kind of file watcher service that looks for changes in real-time instead of inspecting in "Pending changes" update-time that we can use. Best.
  6. Thanks @calbzam. Closing this thread in favor of joining instead. Best.
  7. HI all, joining as we need that particular feature as I've mentioned in I would expect something similar to what @Barron Kane mentioned earlier about Perforce. Will watch this particular thread and close mine. Best.
  8. Hello, One of the repositories we have is a one-branch, data-only repository consisting of quite big binary files. Such files are not mergeable at all and generally we only want access to the last revision as they are raw assets (Photoshop, Maya, etc. files), thus we work on them incrementally. Because of this, we don't need to keep all revisions for such assets, it would be sufficient to store let's say the latest 3 revisions for each of them. Perforce provides per-file way to do so, and we're wondering whether Plastic does provide a similar system or not. We don't need a per-file system, we would be ok with a per-repository one if no other solution exists at the moment. Thank you in advance for your answer. Best, David.
×
×
  • Create New...