A Git repository is available at git.tiki.org and is synced with SVN repository at SF.net, so that developers can either develop using Git or SVN. The complete workflow is being implemented and is documented at Git and SVN combined workflow.
The workflow is now experimental. If you want write access to git.tiki.org, ask Marc Laporte
Here are some tips that will make life easier when changing a development environment from SVN to Git.
Git repository is 5.6GB, compared to less than 800MB when using SVN. That's because the whole history is stored locally. Since Tiki setup depends on a lot of libraries, changing branches in a single repository might be impractical, and having one repository for each directory would consume a lot of redundant disk space. To solve that, start by having a local mirror repository that will be used as reference for all other repositories. This way you can have several repositories that share the local object database. It's like doing a pre-cache of the repository:
$ git clone --mirror firstname.lastname@example.org:tiki.git tiki.reference
clone --mirror email@example.com:tiki.git tiki.reference Cloning into bare repository 'tiki.reference'... The authenticity of host 'git.tiki.org (22.214.171.124)' can't be established. ECDSA key fingerprint is SHA256:bsX1VZ1KCXiUlequpZc6f+JGBG0xO4HpUSyYnVrXbMs. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'git.tiki.org,126.96.36.199' (ECDSA) to the list of known hosts. firstname.lastname@example.org's password:
(This will take some time, have a coffee).
Then, clone the repository using the mirror as reference.
$ git clone --reference tiki.reference email@example.com:tiki.git
Create one repository per branch:
$ git clone --reference tiki.reference firstname.lastname@example.org:tiki.git tiki18 $ cd tiki18 $ git checkout 18.x
Now just commit and push normally, and everything should work fine.
Since Tiki integrates with external services, sometimes one VM per branch is an important setup. One possible setup to solve this is having the tiki.reference in your host and use sshfs to mount it inside your VM:
The instructions below will configure that to be automatically mounted, adjust user and directories to your local setup:
mkdir gitcache su - apt install sshfs fuse autofs modprobe fuse echo fuse >> /etc/modules echo '/home/lfagundes/gitcache /etc/auto.sshfs uid=1000,gid=1000,--ghost' >> /etc/auto.master echo 'tiki.reference -fstype=fuse,rw,nodev,nonempty,noatime,allow_other,max_read=65536 :sshfs\#lfagundes@host\:/home/lfagundes/devel/tiki.reference' > /etc/auto.sshfs exit ln -s gitcache/tiki.reference
The magic synchronization of SVN and Git, done by Subgit, is a complex problem. We've have observed a weird behaviour when commit order is not chronological, probably consequence of a
git pull --rebase. To keep things simpler for synchronization to work as expected, here are some tips:
- Don't use
git pull --rebase. Instead, do a
git fetch; git rebase --ignore-date.
- Avoid git merges inside same branch. If a git pull causes a merge, abort the merge and run the fetch/rebase above.
- Better to push your changes as soon as you commit them, so you don't stack changes with same datetime when rebasing.
Information below concerns the Git repository at GitHub, which used to be synced with sync2git and is not working properly. Information remains here while git.tiki.org is evaluated and implemented.
If you prefer to download Tiki via GIT, which might be more useful for your internal development processes, you can access that mirror here: https://github.com/tikiorg/tiki
Note: This page needs more info on how one can effectively use GIT within one's own development process
Related Question: Will Tiki ever migrate to GIT from SVN? see What ToDo When Migrating To Git for the answer.
- cd into your local mfm git master clone, and make sure it's up to date with
$ git pull
$ git status
- to check you haven't got anything stuck in there to push (if you want to clear any changes and LOSE them do "git reset --hard origin/master")
$ git remote add upstream https://github.com/changi67/tiki.git $ git fetch upstream
- and it should start downloading the entire internet (actually just Tiki i think, takes a while)
- If you get any errors about SSL certificates try "git config --global http.sslVerify false" and retry the fetch upstream one.
- Then to actually do the merge do
$ git pull upstream 12.x
$ git fetch upstream
And you may need to close and reopen your IDE project to show the new branches.
Whenever there is a new committer to Tiki, the sync2git code will fail, as it tries to map the new committer in SVN to the GIT committer, or some other problem might be causing the issue.
First thing to do would be to check /var/log/sync2git.log, or to try running the sync2git again.
If the problem is due to new committer: You will receive an error saying that a certain committer could not be found. On the community server ovh.tiki.org, there is a file: /etc/sync2git/projects/tiki/authors.txt
Add a new line at the end of the authors.txt:
committersfaccountname = committersfaccountname <email@example.com>
But first, make sure the name does not already exist in the file so that you are adding the right committer.
Once you added that line, save the file, and then you need to remove the lock file:
sudo rm /var/lib/sync2git/tiki/.lock
Finally, execute sync2git: