Upgrading from 13.X to 13.X or 14.x releases:
This upgrade involves unpacking the new GitFusion scripts, dropping them into place, then updating the GitFusion triggers if necessary.
(1) before upgrading ensure that all users are no longer in the process of pushing or pulling and that all GitFusion processes are no longer running.
You can either temporarily remove the authorized_keys file to block access, or change the firewall rules that allow connectivity to the gitFusion server.
(2) Backup the original directory.
(3) Download the latest GitFusion release from our Downloads page or FTP site.
(4) Unpack the tar ball and replace the existing 'git-fusion' directory with the new one.
(5) Run 'p4gf_super_init.py'. This will sanity check that all is setup correctly, as well as letting you know if you need to update the GitFusion triggers.
(6) Run 'p4gf_update_hooks.py' to update the post-receive and pre-receive hooks for the existing git-fusion repos. Or, manually remove all the post-receive and pre-receive hooks inside the git-fusion home directory. In the OVA, they are residing inside /fs/git-fusion/.git-fusion/views/REPONAME/.git/hooks directory. They will then be automatically re-generated.
(7) To update the triggers run the following command:
p4gf_submit_trigger.py [--set-version-counter serverport]
(8) Let the users back in.
Important Note: Before commencing please check for updates to these steps in the release notes for the version you are upgrading to.
Upgrading from 12.X to 13.X or 14.X releases:
This is not a trivial upgrade and you should contact Perforce support (email@example.com) before commencing. As part of the conversion process from 12.X to 13.X data the SHA1 values of Git objects will be changed. This will result in user's having to re-clone their repos, then apply any unfinished work as a series of patches.
See the 'Post upgrade steps for users' section below for details.
It is also recommended that you test the upgrade on a test system before performing it in live.
To Upgrade GitFusion:
(1) Quiesce the Git Fusion 12.X system by
- Request all users make final pulls and pushes from/to the system
- Disable the ssh access to the 12.X Git Fusion service
- Turn off any cronjob which is updating the ssh keys
- Ideally, create a checkpoint of the Perforce server and backup the .git-fusion depot
(2) Begin installation of the new Git Fusion version. To install using the OVA or distribution tarball, see the Perforce Git Fusion Guide. To install using packages, see the README included in the package tarball.
For example GF 13.1 has dependencies such as Python 3.3.2. The conversion process requires this version of Python.
Stop when you reach the manual step of running 'p4gf_super_init.py'.
It is important that you do not initialize this new installation with your Perforce server at this time.
(3) Log in to this new install of Git Fusion as the Git dedicated OS account. Set your P4PORT to the Git Fusion 12.X Perforce server and your P4USER to the Git Fusion admin user (e.g. git-fusion-user). Run 'p4 login' to authenticate.
(4) Perform a test run by running 'p4gf_convert_v12_2.py'. Make sure to review the output for any unusual reports. Common issues are below:
Message: Does not look like a Git Fusion 2012.2 installation
Resolution: The conversion script determines if any given Perforce service is configured for Git Fusion 12.2 by checking for a 'p4gf_auth_keys_last_changenum-*' style counter. Verify that the Perforce service that the conversion script is connecting to is the correct server for your Git Fusion 12.X installation, then run the following command to create the counter and allow the conversion script to proceed:
p4 counter -u p4gf_auth_keys_last_changenum-foo 1234
Message: All Git Fusion servers connecting to this server must be disabled (followed by a list of counters indicating activity)
Resolution: Prior to running the conversion script, all Git Fusion instances connected to the underlying Perforce service must be stopped. This includes any cron jobs or automated scripts. Verify that all Git Fusion instances and all automated scripts have been disabled, then re-run the conversion script. If the list of counters persists, then you must manually delete the listed counters using the following command:
p4 counter -u -d <counter_name>
(5) Run the conversion by adding the '-y' flag to the call. This will run 'p4 obliterate //.git-fusion/objects/...' as one of the final steps. Do not interrupt the script while it runs.
(6) Complete the installation of Git Fusion for your Perforce server. See the Git Fusion Guide for details.
(7) Optionally, run 'git clone git@SERVER:REPO' for each defined repository to pre-populate the Git Fusion local cache. Doing this will make first time clones faster, as the information users need is already in the cache.
Post upgrade steps for users:
The conversion from Git Fusion 2012.2 to Git Fusion 2013.1 required the object cache contained within Perforce to be deleted. As a result, re-creating the Git Fusion cache Git repository may generate commit objects which have different SHA-1 values as a result of different
If this is the case each user must clone a new version of each repo needed for his or her work from Git Fusion:
git clone git@GIT_FUSION_HOST:REPO
Users who do not have any outstanding work can just start using the new 13.1 repo and remove the old 12.2 local repo.
Users who have outstanding work to push must use the following procedure to integrate these changes into the new repository.
(1) Identify the latest common commit between the old repo and the new one:
In both the new repo location and the old repo location, run:
git log --pretty=oneline -NN
Find the most recent matching message from these two commands. NN is how many commits to show; try 20 initially and increase if needed to find the most recent matching commit.
(2) In the old repo location, create an empty directory (e.g., patches) and cd into this directory
(3) Using the old repo's most recent matching commit and the very latest commit, generate a set of patches:
git format-patch MOST_RECENT_OLD_COMMIT..LAST_OLD_COMMIT
This will generate one patch file for each commit.
(4) In the new repo location, create a temporary branch:
git checkout -b TMP_NAME
(5) Apply the outstanding patches:
git am PATH_TO_OLD_REPO/patches/0*
(6) Merge/rebase in this branch any outstanding changes from master.
(7) Merge this branch into master.
(8) Push these changes to Git Fusion.
(9) No longer use the old repo.