Although Perforce gave you no choice in the matter, and nothing is left for you to resolve, the outcome is exactly what you wanted. When you submit your changelist, Perforce will delete MAIN/readme and branch V1/readme.txt into MAIN, effectively propagating both the content change and the structural change from V1 to MAIN.Git-p4 supports git lfs out of the box, all you have to do is configure a few settings to let it know which files should go to LFS here's a list of commands to run, with comments to elaborate. #enable git LFSFor demonstration purposes, let's say that changelist number is '1001'. Integrate the main changes into mainbuild, so you can build with everything up to and including changelist 1001: p4 sync //depot/mainbuild/.#set *.lib as LFS extension, repeat for each extension neededGit config -add git-p4.largefileextensions lib#after setting all extensions, run this to list them to double checkGit config -get-all git-p4.largefileextensions#if you made mistakes, run this command to clear extensions and start overGit config -replace-all git-p4.largefileextensions libNote that this Perforce specific configuration, it doesn't impact git side of things so the identified migrated files will be LFS, but new files added directly to git aren't considered LFS unless you configure git correctly, this is configured in another section below. Choosing a migration pointWhile you can migrate all the history into git, you might want to consider overall repository size, and the amount of relevant history typically 2-3 years of history should be enough, but you should have a discussion with developers and decision makers, ensure you've consensus, and document the decision.This is especially important because the Perforce server will be decommissioned sooner or later, which would make access to older history very difficult, if not practically impossible.Once a decision is made, start off the migration from the specified change-list, limiting to a single change list to measure how long it would take.
One can explicitly sync some files to older revisions, and then a single changelist number is meaningless. But you still need to sync everything using that change number.I don't think you can achieve exactly what you want, because in general, an entire workspace isn't synced to a particular changelist number. For a serious build (one that is being prepared for testing), explicitly specify the desired label or changelist number, sync to label, and imbed it in build artifacts.If a changelist (or label) is not given, use p4 counter change to get the current change number, and record it. #import more changes into git, no need to specify the perforce pathThat's it, you have migrated from perforce to git :) Configuring git LFS extensionsWhile this step is not necessary to start using the new repository, it's important so that new files added to git are imported as large files this is done via. Gitattributes file, or by this command #add lib files as LFS, repeat for all the extensions neededNow, all is left is to create a repository on github, and push as required.
It's too easy to be mistaken in those assumptions, hard to detect, and horribly expensive in terms of lost time. In that context, we don't bother to embed a repository label.With your approach, you are making the assumption that your whole workspace was synced to head at the time of your last changelist submission, and that changelist included all of your open files. Our developers don't normally sync as part of a build they do a build prior to submitting—so that they can make sure their changes don't break the build or tests.
...
0 kommentar(er)
