OpenModelica in git instead of svn

[Adrian Pop]

As we got several requests about having OpenModelica in git instead of svn I'm opening this ticket for a discussion about it.

Personally I don't care too much which version control system we're using (well I do, but let's say I'm not).

Pros for git?

• People say it would be easier to contribute code via pull requests from their repository to ours as they would not need an account.
• Faster checkouts?
• Easier merging?

Cons for git?

• While pull requests are great, it still means somebody needs to verify the changes and approve them and commit them. Which means yet more stuff for us to do.
• Harder to use/understand than svn?

While this is maybe an OSMC board decision, it would be good to have more input on this from the OpenModelica developers.

Please comment on this ticket your views.

[Christian Schubert]

I would like to add a third option: Mercurial.

Mercurial has most of the benefits of git, but is much less complicated.
Furthermore, the graphical client TortoiseHg (available for both Windows and Linux!) is as intuitive as TortoiseSVN. The TortoiseGit client, however, is extremely difficult to understand.

A pro for moving away from svn would be the possibility to commit locally without making this commit publicly available. Thus I can save a state without annoying other people. This can be very helpful to save intermediate versions to which I can revert back to, if things went wrong. To get the same feature with svn, I had to use patches, create a branch or set up a mercurial repository on top of it.

[Adrian Pop]

While local commits are great for managing local code changes I think they are a risk.
The risk comes from the fact that they are not backed up and they might be lost if the
local computer hard drive crashes. The openmodelica.org performs *several* backups
of the svn repository per day so working on a branch in it would be much safer.

[Martin Sjölund]

It is easy to backup your git repository though. I have a lot of scripts to essentially upload unstaged changes in my subversion checkout to the test servers. This fails if I delete or move files around, etc.

With git I would instead be able to go to say dev.openmodelica.org and just git pull from the machine I am currently working on and it would create a new copy of my changes. Which I can revert locally and when it is time to merge with the master branch, I could squash them into one commit.

I could also keep just the one checkout and work on two branches at the same time, switching between them.

Once you get a hang of the work flow, it is pretty nice.

As for hg, I would have to see how it deals with external repositories. The fact that it can keep both svn and git externals looks cool, but I wonder if it works the way I want it to track repositories...

[Adrian Pop]

sjoelund.se, without other evidence I guess you and me are the only ones that backup their local changes. Any others that do that?

[tom short]

I like git. It has support from many tools (hosting, add-ons, backups, editor support, and more) and seems to have the biggest user community by far.

It did take me a while to do even simple things with git, but it's easy to google almost any problem you have with it. I either use the command line or magit with emacs.

I really like having a local history of commits. That part is so much better than SVN that for some projects, I'll use git-svn to use git locally with a remote svn repository.

As far as pull requests and extra workloads, that's really up to you and how you manage the workflow. At least with github, you can give folks permissions to commit at will. I tend to like pull requests in that it encourages code reviews.

As far as backups, you can push to a branch in a repository that gets automatically backed up. Because you're on a branch, you can commit and push like crazy without worrying about your effect on others. Once you're happy with your changes, you can then do a pull request (or a merge) against master or whatever branch is designated as the main branch.

[Martin Sjölund]

OK. From testing mercurial a few minutes, its handling of external repositories is really, really good. The svn externals works better than they do in svn (if they are up-to-date, it will not try to contact the svn server, meaning hg pull would not be slow even if there are 20 or 30 different repositories).

It seems to support subpaths into svn just like svn externals. But just like git itself, only the root directory of a git repository.

As usual I do not care about GUIs :)

My main concern would be how nice merging in it would be. Some of my favourite commands in git are git commit --amend, rebasing, feature branches, and squashing merges. The web pages comparing git and hg suggest this is not possible in hg :(

So both have their pros and cons...

[Martin Sjölund]

As for github, it is really nice. And while we could mirror the repository you would need one master.
If github is the master, we cannot commit if it goes down. Well, we could, but if it is a temporary denial of service you do not want to edit stuff in a slave...
And if the github repository is not the master, you lose a lot of the automatic merging of pull requests. Which to be honest is a real time saver.

Or does anyone know of a flawless 2-way synchronised git mirror?

[Willi Braun]

I'm in favour to switch, as far as I understand till now, the advantages can improve the workflow, in particular working with a local repository and split-up a larger local changes into several commits.

Replying to adrpo:

sjoelund.se, without other evidence I guess you and me are the only ones that backup their local changes. Any others that do that?

Of cause, I use patches and backup them on different computers.

[Willi Braun]

What's about the history if we move to git, will the history keep or do we lose there something?

[Martin Sjölund]

We keep it. Except for svn:externals I think everything is kept. git-svn is pretty powerful.

[michael.tiller@…]

I'm in favor of Git. I actually used Mercurial as my main DVCS when I started Xogeny. But I eventually moved to Git. I agree that Mercurial is more consistent and friendly. But there is so much momentum behind Git, that I eventually just went with it since most of the other projects I was touching were using it.

I back up all my machines continuously. So I'm not worried about the risk of loosing commits. Quite the opposite since I can commit when I'm offline.

I also think pull-requests are a huge win.

(this is Michael Tiller, BTW...my svn credentials failed to log me in here)

[Henrik Tidefelt]

At Wolfram MathCore, a majority of developers already use git svn on top of Subversion, so it has been a natural decision to plan a switch to Git for the central repository.

[anonymous]

I agree to Micheal Tiller: pull-requests are a huge win! This creates a 4-eye-check for code contributions.

You don't have to worry about local commit backups. I'm using bitbucket to work on ogre. All my local changes are pushed to my fork of the ogre project. The pull-requests are made from my fork to the main project. It would be nice to use a public platform like github or bitbucket to use this backup function on openmodelica. Also the user management is really easy on this sites. I like bitbucket because everybody can see the pull-request, give feedback to it or add a comment.

GIT example:
boost moved from SVN to GIT on github (​https://svn.boost.org/trac/boost/wiki/ModularBoost). Take a look at boost's github page at ​https://github.com/boostorg. boost is using a super-project with a few common files and include the libs as dependency projects.

HG (Mercurial) example:
I also have a good working example for a project which is using bitbucket: ​https://bitbucket.org/sinbad/ogre.

Links:
​http://blogs.atlassian.com/2012/03/git-vs-mercurial-why-git/
​http://blogs.atlassian.com/2012/02/mercurial-vs-git-why-mercurial/

Regards,
S.

[Adrian Pop]

I will bring this up in the next OSMC board meeting, 20 May or so.
We'll see what they decide.

[Martin Sjölund]

So I remember: if we do move to git, we could setup a nicer workflow for commits.
Let's say we have a mirror service on a github account:

1. user makes a pull request
2. a developer checks and approves the request (assume it can be automatically merged; else developer manually has to merge)
3. the developer triggers our hudson to fetch the given pull request
4. hudson builds OpenModelica and runs the tests
5. the tests succeed, triggering hudson to accept the pull request and push it to the real repository
6. automatically close the github pull request through their API (extra credit)

Have all commits go through such a process (for developers, just tell hudson the the branch, optionally the commit hash, and of course the URL of the hosted repository - dev.openmodelica.org or your own server).

[Adrian Pop]

Hi all,

The OSMC board decided to let it up to the developers if we switch to GIT
(or not) as long as the master repository is hosted at openmodelica.org.

As far as I can see from the discussion we should do it.

I propose we do it after the 1.9.1 release in a couple of weeks as we will have more time.

If we switch to GIT we should also split it up into several projects:
OMC (compiler)
QtClients (OMEdit, OMNotebook, OMPlot, etc)
Any other things we should split up?

I'll have a look on how the SVN and Trac history can be preserved if we split up the current repository.

Cheers,
Adrian Pop/

[Martin Sjölund]

We have things that are peripheral and could be split up into additional projects. For example Modelica3D (we could even split it out of OpenModelica, just the installers). Using git all the way we could also redesign gitlibraries a little. We have some non-Qt clients as well (OMShell-terminal, OMPython). And of course, the testsuite and some place to store reference files.

[Martin Sjölund]

Some software to host git projects (to evaluate):

• Allura (the self-hosted version reports service unavailable; which is not a good sign)
• Gitblit (cool API, pull requests, SSH, LDAP)
• Gitlab (paid version has the coolest features; the free version should have sufficient features though)
• Github backed up with local read-only mirrors (github as master)
• Gitorious (only supported on CentOS)

[michael.tiller@…]

I prefer GitHub mainly because it is easier to find that way. With GitHub, I don't have to go "hunting around" for some self-hosted server somehwere on the internet. Of course, you can always mirror to GitHub, but then I don't know how well pull requests would work.

If you DO decide to use some self-hosted system, PLEASE use one that uses OAuth and can authenticate against GitHub. That way at least I don't need to have a separate account and keep track of the passwords for it. Ironically, this comment is anonymous because even though I *kept track* of my username and password it doesn't seem to work anymore?! This is exactly the reason why I'd prefer some kind of federated identity system for authentication.

(this is Michael Tiller, BTW)

[Martin Sjölund]

Authentication to push changes is easy: use SSH public keys (I think all of the mentioned solutions use it).

Gitblit can create tickets without using the web gui (git push upstream HEAD:refs/for/new). Although you do need a password (LDAP supported, so it can be shared with the trac password).
Gitlab has oauth integration it seems ​https://groups.google.com/forum/?fromgroups=#!topic/gitlabhq/6JQukF88GZ8
Gitorious does OpenID or its own
Allura I am not sure

[anonymous]

Github or Bitbucket would be fine, because they are the most polular platforms with a lot of integrating features. If you don't like it you could also have a look at Sourceforge and Codeplex. All platforms are supporting Git. Three is no need to host open source software on a private server. Instead of investing time into server administration you could work on OM.

[Lennart Ochel]

I prefer GitHub as well.

[Martin Sjölund]

Well... We used to use svn:externals into github. But it kept going down, so we mirrored the repositories locally anyway. We have to do that for backups also.

[anonymous]

Replying to sjoelund.se:

Well... We used to use svn:externals into github. But it kept going down, so we mirrored the repositories locally anyway. We have to do that for backups also.

You could create repositories for all externals and include them as submodule in Git as well. Have a look at boost (​https://github.com/boostorg). Each library has an own repository which are combined in the super project as submodules in libs folder.

[Martin Sjölund]

My point was that github is not reliable; that the connection between LiU and github often went down so we could not run the tests. We will use git submodule or separate projects for different parts of OpenModelica regardless.

But, we will probably need to mirror the github repositories regardless. Because we have a lot of jobs that would trigger on commits to the repositories, and if a subsequent job fails to query the server (github), it fails and we need to restart the job manually.

So... we will need to maintain some infrastructure locally regardless of what operator we choose. Especially considering that we need reliable backups.

[anonymous]

Replying to sjoelund.se:

My point was that github is not reliable; that the connection between LiU and github often went down so we could not run the tests.

I can't confirm that, but there are a lot of public hosters: bitbucket, github, sourceforge, codeplex, gitorious, etc. I would prefer bitbucket but github is also ok.

So... we will need to maintain some infrastructure locally regardless of what operator we choose. Especially considering that we need reliable backups.

Feel free to create a job to clone the github repository to your local computer.

But, we will probably need to mirror the github repositories regardless. Because we have a lot of jobs that would trigger on commits to the repositories, and if a subsequent job fails to query the server (github), it fails and we need to restart the job manually.

You don't have to poll github. They have a notification API which can send you information on each commit. You can also use this to update your local backup and you can run the test on your local backup.

[anonymous]

I like the idea of github, too. A lot of developers have an github account. They could create pull requests without creating a new account. And you don't have to contact Adrian for an account. Also, it's a good point to have a page on such a large site. If someone search for a modeling tool on github he could find OM.

[anonymous]

Anything new on this topic?

[anonymous]

Replying to adrpo:

As far as I can see from the discussion we should do it.

I propose we do it after the 1.9.1 release in a couple of weeks as we will have more time.

If we switch to GIT we should also split it up into several projects:
OMC (compiler)
QtClients (OMEdit, OMNotebook, OMPlot, etc)
Any other things we should split up?

1.9.2 has been released. Anything new on this topic?

[sfbosch <posting@…>]

I am throwing in my vote for a switch to git as well. I understand the hesitation of people accustomed to more traditional version control systems, as git does require a change of perspective if you want to really maximize its power. Once you have done the homework, though, it's pretty amazing (and the online documentation is excellent). I use it everywhere, also for managing document revisions in LaTeX, as it takes two seconds to type 'git init'. I like the ease of creating and merging branches, too (though I haven't used mercurial, which is perhaps as good in this regard, I don't know).

I think git would make it easier for people to contribute to OpenModelica.

I like github also, but I can understand if OSMC doesn't want to have anything sitting on a hosted service in the United States. If the locally-hosted repo manager can offer some of the same functionality as github, then that approach is fine.

[Martin Sjölund]

r25798 moves OMPython to ​https://github.com/OpenModelica/OMPython (pip install works)
OMOptim will be moved to ​https://github.com/OpenModelica/OMOptim. I am working on updating the builds so OMOptim and omc are built in separate packages; OMOptim rarely changes so it does not make sense to download a new one every day... or supporting it on all platforms (latest Debian release lacks g++-4.4 and so cannot compile OMOptim).

[Martin Sjölund]

The following now have a git repository and are read-only (really: svn:needs-lock) in the svn:
​https://github.com/OpenModelica/OMEdit
​https://github.com/OpenModelica/OMNotebook
​https://github.com/OpenModelica/OMPlot

OMPlot has makefiles setup. The others I will add as I have time.

[Martin Sjölund]

Added a repository for large files that are not really source files (such as OMEdit psd's, which triples the size of the OMEdit repository):
​https://github.com/OpenModelica/OpenModelica-extra

[Martin Sjölund]

Not all ReferenceFiles directories will be moved to the new repository; the reason is that some of the files are huge for no good reason (I got the msl32 reference files down to 21MB from 625MB, mostly by running the mos-script and when getting reference equal replacing the reference with the current file which only contains the variables that are being compared).

We should probably fix the repository to have a single directory for ReferenceFiles that are passed to all mos-scripts (possibly through an env.var). Because a lot of directories also use the same DoublePendulum reference, but copies it since symlinks do not work on Windows.

[Martin Sjölund]

Big superproject is up (but testsuite and omc take ~20 hours to run the branch filtering so they are not added yet): ​https://github.com/OpenModelica/OpenModelica

OMEdit compiles now.

The plan is that each repository should compile stand-alone without the other repositories assuming the dependencies have been installed to for example /usr (that is the way the debian packages will be built).

The super-repository will compile everything in a good order and install into the same build directory we have today. You will just need to take care about git submodules and commit+push things in the right order.

I am thinking that only me, Adrian, and hudson will have commit access to the super project. And hudson will automatically commit the references of the super-packages when the packages build and the testsuite is stable.

Some of the projects have pre-commit hooks to trim trailing whitespace so we do not need hudson to do that for us. It should be extended to also handle UTF-8, etc.

[Martin Sjölund]

I have now made svn read-only (I hope). ​https://github.com/OpenModelica/OMCompiler is not quite ready yet, but will be soon enough.
The testsuite I need to redo some jobs as git failed to rewrite the index.

[Martin Sjölund]

​https://github.com/OpenModelica/OMCompiler is ready for commits.
As is ​https://github.com/OpenModelica/OpenModelica-testsuite.

Note that the test suite is not yet at 100%, and hudson does not run automatically. But it is possible to work against the projects.

[Ruediger Kampfmann]

The actual GIT project aswell as the SVN project cannot be compiled.
It fails in ModelicaParser_omc.c -
When do you think we have a working copy under GIT again?

[Lennart Ochel]

Replying to RuedKamp:

The actual GIT project aswell as the SVN project cannot be compiled.
It fails in ModelicaParser_omc.c -
When do you think we have a working copy under GIT again?

I think this is only windows related. On linux everything compiles fine.

[Ruediger Kampfmann]

Ok maybe windows is the problem.
But who can fix this?

[Lennart Ochel]

Probably Adrian.

[Adrian Pop]

Strangely for me it works fine. I'll try to debug this together with Lennart.

[Adrian Pop]

The issue seems to stem from the fact that git line endings on Windows for Modelica.g are set to CRLF.
Martin, do you know how to set Modelica.g to LF for everybody?
Because Modelica.g is not set to LF the macro definition of modelicaParserAssert in ModelicaParser.h is spread over several lines.

I set my GIT to get the files as they are and commit them as they are so no line ending conversion is happening.

[Adrian Pop]

You can fix the compilation problem on Windows by deleting (BACKUP YOUR CHANGES) and re-checkout the OMCompiler repository as Martin added new git attributes for .g files.
Alternatively you can change the line endings in Parser/Modelica.g to LF using for example Notepad++.

[Ruediger Kampfmann]

A re-checkout doesn't fix the problem.
Only the Notepad++ option works.

Will OmDev also moved from svn to git?

[Martin Sjölund]

I would guess that the current OMDev is fine in svn since svn copes better with binary files than git. But the future OMDev might not depend on so many binary files being precompiled.

[Martin Sjölund]

Well, I would guess git reset --hard would really reset the line endings. But clean checkouts should get the correct line endings.

[Niklas Worschech]

We have the problem that the omlibray is not installed in the build/lib folder with the omc build. Can you tell us please how to do this.

[Martin Sjölund]

You build it from the libraries folder in OpenModelica.git

[Niklas Worschech]

The libraries folder does not have a windows make file. And the normal one does not work.

[Niklas Worschech]

And how can I call it please? If I call just make in the libraries folder I will get this error:
which rm > /dev/null
which svn > /dev/null
which: svn: unknown command
make: * [config.done] Error 1

[Adrian Pop]

On Windows to install the libraries you currently need git and python and some library on top of python.
Until we make a lighter version of the libraries project that needs only git i suggest you copy the omlibrary folder from your OpenModelica Windows installation to build/lib/.

[Niklas Worschech]

I called it from the git folder.

[Nils Menager]

When will this lighter version of the libraries project be available?

[Adrian Pop]

Replying to nimen:

When will this lighter version of the libraries project be available?

Either tomorrow or on Thursday, it depends a lot on how things are progressing as we're trying to make everything work again and also be a bit better than before.

[Nils Menager]

When starting the testsuite, I get the error, that omc-diff is missing. I assume, that this tool is not built when building the OMCompiler. How can we fix this?

[Martin Sjölund]

omc-diff is created by the runtests.pl script.

[Adrian Pop]

Replying to sjoelund.se:

omc-diff is created by the runtests.pl script.

The runtests.pl script does not work on Windows so omc-diff is build differently.

I'm working on adding a Makefile.omdev.mingw on the top OpenModelica project to build omc-diff and deal with other things we need on Windows.

[Adrian Pop]

I now added a Makefile.omdev.mingw to the top project:
​https://github.com/OpenModelica/OpenModelica
If you checkout this one (including the submodules OMCompiler, etc) it will be basically as it was before. It will build omc in OpenModelica/build and not OpenModelica/OMCompiler/build.
Also it builds omc-diff now when building omc.

[Adrian Pop]

Now when you build OpenModelica glue project (​https://github.com/OpenModelica/OpenModelica) on Windows it will also install the libraries in OpenModelica/build/lib/omlibrary. You will need to have git in your path.
You can get the command line git for Windows from here: ​http://git-scm.com/download/win but I guess you already have it.

[anonymous]

Hi,

I get an error executing 'make install' in OMCompiler/ [1]. The reason is an explicit path in Makefile.common (GIT):
top_builddir = $(OMBUILDDIR)
builddir_bin=$(OMBUILDDIR)/bin
install: install-dirs

echo Installing OpenModelica...
# Application directory (OSX)
if [ "$(APP)" = ".app" ]; then cp -rp ${builddir_app} $(INSTALL_APPDIR); fi
# Binaries
cp -a ./${builddir_bin}/* ${INSTALL_BINDIR}

Under SVN it was 'top_builddir = .'.

It would be nice if anyone can fix this.

[1]
# Binaries
cp -a .home/mf/opt/HPCOM/openmodelica/OpenModelica/OMCompiler/build/bin/* /home/mf/opt/HPCOM/omc-trunk-gcc/bin
cp: cannot stat '.home/mf/opt/HPCOM/openmodelica/OpenModelica/OMCompiler/build/bin/*': No such file or directory

[Christoph <buchner@…>]

One thing I noticed about the .gitmodules file in the OpenModelica root project: The URL should point to the public URL on Github, not the local ../XX.git
See also ​here:

Since the URL in the .gitmodules file is what other people will first try to clone/fetch from, make sure to use a URL that they can access if possible.

That page in general gives a good overview over the workflow when using and working with git submodules.

[Martin Sjölund]

No, it does not reference the local file. It references ../ in the repository that you cloned. Because a git-file counts as a folder, ../ is correct and not ./ or just the repository name (this is also how git submodule init / update finds the URL).

It should not point to an absolute path since we intend to mirror the repositories.

[Martin Sjölund]

Replying to anonymous:

cp: cannot stat '.home/mf/opt/HPCOM/openmodelica/OpenModelica/OMCompiler/build/bin/*': No such file or directory

This should be fixed now. I also re-added compilation of the translation files.

[Christoph <buchner@…>]

No, it does not reference the local file. It references ../ in the repository that you cloned. Because a git-file counts as a folder, ../ is correct and not ./ or just the repository name (this is also how git submodule init / update finds the URL).

Ah, nice trick! Too bad Github does not recognize it, too, otherwise you'd get nice links to the submodules/commits instead of grey text in the repo view.

[Niklas Worschech]

I get the errors:

# Building git/BioChem
# Building git/MSL
# Building git/ThermoPower
# Building git/ThermoSysPro
./checkout-git.sh 'git/BioChem' '​https://github.com/OpenModelica/BioChem.git' 'master' 'b5f3cb999f3cfad2bbb6fb429b496f61ecf2f628'
./checkout-git.sh 'git/MSL' '​https://github.com/modelica/Modelica.git' 'release' 'v1.6'
./checkout-git.sh 'git/ThermoSysPro' '​https://openmodelica.org/git/ThermoSysPro.git' 'maint/3.0' 'd4f9c3ed35f7520f82439eb6e9f4057ae0f82b73'
./checkout-git.sh 'git/ThermoPower' '​https://github.com/modelica-3rdparty/ThermoPower.git' 'master' 'e012268625dd1645fe5570cf31d64129d83a8192'
[git/BioChem] does not exist: cloning ​https://github.com/OpenModelica/BioChem.git
[git/ThermoSysPro] does not exist: cloning ​https://openmodelica.org/git/ThermoSysPro.git
[git/MSL] does not exist: cloning ​https://github.com/modelica/Modelica.git
[git/ThermoPower] does not exist: cloning ​https://github.com/modelica-3rdparty/ThermoPower.git

when I build omc on windows. The omlibrary folder is empty.

[Martin Sjölund]

There are no errors listed here though. Is this the full log? -j1?

[Niklas Worschech]

Sorry, this is the error that we get:
Cloning into 'git/ThermoPower'...
Cloning into 'git/MSL'...
Cloning into 'git/BioChem'...
fatal: unable to access '​https://github.com/modelica/Modelica.git/': Could not resolve host: github.com
fatal: unable to access '​https://github.com/OpenModelica/BioChem.git/': Could not resolve host: github.com
fatal: unable to access '​https://github.com/modelica-3rdparty/ThermoPower.git/': Could not resolve host: github.com
make[2]: * [MSL] Error 1
make[2]: * [BioChem] Error 1
make[2]: * [ThermoPower] Error 1
make[2]: Leaving directory `/d/Projekte/OpenModelica/libraries'
make[1]: * d/Projekte/OpenModelica/build/lib/omlibrary/20150507_131230.core Error 2
make[1]: Leaving directory `/d/Projekte/OpenModelica/libraries'
make: * [omlibrary-core] Error 2

[Martin Sjölund]

That sounds like a DNS problem. Contact your sysadmin? Visiting the URL directly in IE works fine? Maybe some proxy settings in the gitconfig is needed?

[Henning Kiel]

Now, that OM has been migrated to Git(Hub) for quite some time, I'm still struggling with git and the process.

An in-depth manual should be out there how to cope with OpenModelica repository. Considering that using submodules it is a very complicated structure.

For example, I do not manage to keep my fork up-to-date, and pull requests are even more difficult.

What I did was:

• fork the repositories on github

-> but how to keep them up to date with the original ones?

• I checked out (cloned) according to README.md, but that gives only reference to ​https://github.com/OpenModelica/OpenModelica and not the one forked one.

What is the correct way to e.g. change one file in OpenModelica/OMCompiler/3rdParty/ and contribute that change?

How do you folks work with git? Command Line? SmartGIT? GitHub Desktop?

I would like to see instructions (with examples) for command line, this should make it easier to understand what needs to be done.

[Martin Sjölund]

The README.md makes you use the main repository for reads, and your fork for pushing. You should anyway never, ever make a change to the master branch. You will do something like:

git checkout -b ticket-xxxx
git fetch origin
git reset --hard origin/master
# make changes
git push -u github # pushes ticket-xxxx to the github fork

There are very many different ways to work with git.

[Martin Sjölund]

Moved to new milestone 1.9.4

[Martin Sjölund]

Milestone pushed to 1.9.5

[Martin Sjölund]

Milestone renamed

[Martin Sjölund]

Ticket retargeted after milestone closed

[Martin Sjölund]

Milestone moved to 1.12.0 due to 1.11.0 already being released.

[Francesco Casella]

OpenModelica development has been on Git for a while, and I'd say with a very positive outcome, so I guess we can close this ticket now.

[anonymous]

Is there some documentation or report of even conference paper on how you did the migration, what went well, what went not so well, what the "positive outcome" is and so on? What about Trac versus github issue tracker? What about github wikis? Do you use github pages, ReadTheDocs, TravisCI, Jenkins, etc?
Thanks for any insight.

[Adrian Pop]

There is no documentation on the migration.

We basically just used svn to git tools to export the repository to git/github so we could keep the history.
We use Hudson/Jenkins to run tests on pull requests, build releases and documentation.
We also mirror the git repo on our own servers as you never know when github might vanish.

We are still using Trac and not the github issue tracker, one needs to adapt to use ticket:number instead of #number in the commit logs as #number is used for PRs in github.
OpenModelica is much more robust now because we run tests before committing anything, which was not the case with svn.

Compared with svn there is a bit of a learning curve with git, you need to change your patterns, use command line more, but it is much more flexible and way faster (minutes via git clone vs hours via svn checkout for OMDev, our windows mingw based development environment).

[Martin Sjölund]

Replying to adrpo:

We basically just used svn to git tools to export the repository to git/github so we could keep the history.

Actually, we also split the SVN repository into several parts, which made things more modular. But made it awkward to use a normal PR-CI tests PR-review PR-merge workflow.

We use Hudson/Jenkins to run tests on pull requests, build releases and documentation.

We do a PR-review-run Hudson which pushes to the master if Hudson reports no errors. This is slightly backwards, but has worked rather well.