# git-p4.py caching 2 messages from 2017-02-14 to 2017-02-15. Participants: Martin-Louis Bright, Lars Schneider. Thread: https://gitlist.dev/t/45140 ## Martin-Louis Bright, 2017-02-14 18:16 Subject: git-p4.py caching Message-ID: URL: https://gitlist.dev/e/CAG2PGsqs2dQM0SJ25ocHJ%2BNex_m2NC5yQQuROxcF6SG2e93wCQ%40mail.gmail.com ``` hi! I am using git-p4.py to migrate a lot of medium and large Perforce depots into git. I almost exclusively go one way: from Perforce to git. I also frequently re-clone/re-migrate as the Perforce migration client spec is refined. For this, I have added rudimentary caching in git-p4.py so that Perforce requests are not repeated over the network. I have it working and tested on a ~150MB repo and the migration time was halved. Is this something that would be of interest to the larger community? --Martin ``` ## Lars Schneider, 2017-02-15 13:10 Subject: Re: git-p4.py caching Message-ID: URL: https://gitlist.dev/e/A8AD20AC-C069-4572-9C6A-519E1855220F%40gmail.com In-Reply-To: ``` > On 14 Feb 2017, at 19:16, Martin-Louis Bright wrote: [CC'ing Luke and George] > hi! > > I am using git-p4.py to migrate a lot of medium and large Perforce > depots into git. I almost exclusively go one way: from Perforce to > git. I also frequently re-clone/re-migrate as the Perforce migration > client spec is refined. > > For this, I have added rudimentary caching in git-p4.py so that > Perforce requests are not repeated over the network. Martin implemented an on disk cache and "requests not repeated" applies mostly for re-migrations. Re-migrations are multiple test migrations ("git-p4 clone") with minor client spec changes until we find the right client spec for the production migration. > I have it working and tested on a ~150MB repo and the migration time was halved. > > Is this something that would be of interest to the larger community? I like the idea! Disclaimer: I work together with Martin on the P4 -> Git migrations :-) Cheers, Lars ```