• From: Gothenburg, Sweden
  • Registered: 08-09-2009
  • Posts: 1,419

Topic: What about using distributed version control (GIT) ?

How do everyone else here feel about Distributed Version Control Systems (DVCS)? (Id like to hear from as many as possible, especially those who actually don't have write access to SVN)
Of course, I wouldn't have made this post if I didn't think it would be an improvement.

There are various advantages, but the main reason for to suggest this is to make it easier for people without central write-access to work and contribute in OOFEM.

First, It could either by through a hierarchy of trust; someone requests that i pull their commits, which after review I could push towards the master branch.
There wouldn't need to be many people with actual write access to the master branch.

Secondly, new users wouldn't even have to properly format patches and such, just commit their own code to their branch, and then request a pull. I personally find it less daunting to make smaller contributions to projects with this approach.
And, as a user doesn't have anything worth committing, but would still like to track their changes, its vastly superior to using SVN.

For larger features, being able to commit several things (locally) before a pull request is ready is absolutely vital. I know that before I was allowed write access, my work flow was far less convenient.

-----------------------------------------------------------

Part of the reason I'm asking this is due to the fact that OOFEM is being considered for a joint research platform here at the department of Applied Mechanics. Nothing is decided yet, but if that is decided, one could expect that there would be quite a few new users actively contributing.
In that scenario, being able to commit code without pushing anything central is absolutely vital, since it could take up to a year before you have any new feature stable and ready for public release. Up until that point, being unable to commit anything to SVN would be nerve-wrecking to say the least. And handing out write access to everyone wouldn't be very attractive. The point is that the VCS should be there to make life easier for everyone.

  • Registered: 16-06-2012
  • Posts: 1

Re: What about using distributed version control (GIT) ?

I have used GIThub for some projects and this has been what convinced me to drop CVS/SVN for all but some ancient single-user projects. The ability to make a branch with one click, and to never worry about who should have write-permissions, means I will never look back. I would certainly up OOFEM several notches as an alternative to hacking my own code if it was using git.

I think the main reason against GIT - the horrible user interface - has been eliminated now. Two years ago is was clunky but now it's e.g. integrated in eclipse, has a pure java implementation and runs smoothly on windows.

  • From: Gothenburg, Sweden
  • Registered: 08-09-2009
  • Posts: 1,419

Re: What about using distributed version control (GIT) ?

I want to bring this up again.

A few colleagues of mine will be starting to work with OOFEM for an XFEM research project.
They will of course need their own branch with version control, since it'll probably be a fairly long time before anything is feature complete to merge back into trunk.
For many understandable reasons, working on a SVN-branch on http://www.oofem.org/svn is not an option.

I also find myself holding back on committing code modifications for longer than I would want, but since SVN branching is tedious, I just choose to withhold it until its presentable in trunk.


Since I never got any replies to this thread initially, so I'm falling back on my backup plan;
I will do a "git svn clone" and fork it on github, so that my colleagues can in turn fork, modify and send pull requests to me, which I could possibly merge back into svn trunk.
I'm not sure how well this will play out. I really hope this won't lead to a permanent fork just because centralized version control is so inherently broken, but staying with a single svn repo on oofem.org is just not a viable option.

4 Reply by bp

  • bp
  • Administrator
  • Offline
  • From: Prague, Czech Rep.
  • Registered: 02-03-2007
  • Posts: 1,047

Re: What about using distributed version control (GIT) ?

I have already spend some time looking on GIT, based on forum feedback. From our side, there is no objection on this.
It is on my todo list for a while, the only problem is the time needed to set up and convert repositories.
I can promis to do it in the near future (in a few weeks), definitely before the next stable release, that should be released this year as well.

Borek

bp's Website

  • From: Gothenburg, Sweden
  • Registered: 08-09-2009
  • Posts: 1,419

Re: What about using distributed version control (GIT) ?

Sounds good.
Please give me a heads up when you plan on doing the change (so that I might possibly squeeze in a last commit before its time to convert the repository).

As for the conversion process, authors should be converted to GIT style (which is a full name and email address). I'll send you an email of what author name I'd like.

For anyone else with commit access who might read this; The conversion tools need to know what authors should be converted to, so if you have a preferred email adress you might want to send this information to Borek. The author conversion file is just a text file containing

mysvnauthor = My Name <my.email@someplace.com>

6 Reply by bp

  • bp
  • Administrator
  • Offline
  • From: Prague, Czech Rep.
  • Registered: 02-03-2007
  • Posts: 1,047

Re: What about using distributed version control (GIT) ?

I have started to play with server installation, initially I have decided to use http(s) protocols (the same as used for svn repository now), but unfortunately this particular option is not so well documented and I have ended up with strange errors, searching the net did not help. So at present I am thinking for ssh r+w access for a few core contributors (they have to send their ssh keys) with public http based read access.

Concerning the distributed model, I am considering so called Dictator and Lieutenants Work flow model described in git book (http://git-scm.com/book/en/Distributed- … -Workflows), where core developers with act as lieutenants, responsible for merging the developers’ topic branches into their master branch.

Any comments are welcome.
Not yet tried to perform svn git conversion, just playing with small testing project.

bp's Website

  • From: Gothenburg, Sweden
  • Registered: 08-09-2009
  • Posts: 1,419

Re: What about using distributed version control (GIT) ?

I expect to be a lieutenant for contributions from my department, although if the number of developers increases, there would probably be some heirarchy within the department.

I would think that the main question for you is whether or not you want to give out (selective) push access, or just recieve pull requests.

8 Reply by bp

  • bp
  • Administrator
  • Offline
  • From: Prague, Czech Rep.
  • Registered: 02-03-2007
  • Posts: 1,047

Re: What about using distributed version control (GIT) ?

I propose to use a two-phase merge cycle, as described in git book (http://git-scm.com/book/en/Distributed- … -a-Project): In this scenario, you have two long-running branches, master and develop, in which you determine that master is updated only when a very stable release is cut and all new code is integrated into the develop branch. Lieutenants regularly push develop branches to the public repository. Each time you have a new topic branch to merge in (Figure 5-21), you merge it into develop (Figure 5-22); then, when you tag a release, you fast-forward master to wherever the now-stable develop branch is (Figure 5-23).

Nice would be to rebase contributed work on top of developer develop branch, rather than merging it in, to keep a mostly linear history. When you have work in a topic branch and have determined that you want to integrate it, you move to that branch and run the rebase command to rebuild the changes on top of your current develop branch. If that works well, you can fast-forward your master branch, and you’ll end up with a linear project history.

In reference repository, I would expect only two branches: master and develop. The releases will be tagged. In the case of necessary fix of release version, a fixing branch may be started, followed by tagging of fixed release and merging into develop branch.

bp's Website

9 Reply by bp

  • bp
  • Administrator
  • Offline
  • From: Prague, Czech Rep.
  • Registered: 02-03-2007
  • Posts: 1,047

Re: What about using distributed version control (GIT) ?

I have noticed that there was an error during the nightly build, so I can postpone the shutdown of write svn access to Monday afternoon, so that hopefully the error will be resolved before conversion.

bp's Website

  • From: Gothenburg, Sweden
  • Registered: 08-09-2009
  • Posts: 1,419

Re: What about using distributed version control (GIT) ?

I'm currently investigating what goes wrong in the brazil test. I can't imagine any of the code i committed could cause (what seems to be) convergence problems for brazil_2d_nl2.oofem test. I will at least try to track down the commit

11 Reply by bp

  • bp
  • Administrator
  • Offline
  • From: Prague, Czech Rep.
  • Registered: 02-03-2007
  • Posts: 1,047

Re: What about using distributed version control (GIT) ?

ok, git repo is online, with public read access. See new post in announcements.

bp's Website

12 Reply by bp

  • bp
  • Administrator
  • Offline
  • From: Prague, Czech Rep.
  • Registered: 02-03-2007
  • Posts: 1,047

Re: What about using distributed version control (GIT) ?

Lieutenants: please send me your public ssh key, which is needed to grant you write access to reference repository (see http://git-scm.com/book/en/Git-on-the-S … Public-Key for reference)
Then I will send you instructions from where to clone.

I did not yet prepared any instructions for you, but in general: (taken from my previous post here):

- two-phase merge cycle, as described in git book (http://git-scm.com/book/en/Distributed- … -a-Project): In this scenario, we have two long-running branches, master and develop, in which master is updated only when a very stable release is cut and all new code is integrated into the develop branch.
- Lieutenants migrate the contributed work and regularly push their develop branches to the public repository.
- rebase contributed work on top of developer develop branch, rather than merging it in, to keep a mostly linear history. When you have work in a topic branch and have determined that you want to integrate it, you move to that branch and run the rebase command to rebuild the changes on top of your current develop branch. If that works well, you can fast-forward your develop branch, and you’ll end up with a linear project history.

bp's Website

  • gustel
  • Senior Member
  • Offline
  • Registered: 16-04-2007
  • Posts: 102

Re: What about using distributed version control (GIT) ?

With the git transition in place, could someone advise me what the best way is to create a version of oofem on a server such as github which would follow changes in the develop branch, but would allow my collaborators to add changes in my version of oofem which are not ready to go into the develop version?

I tried just now the following:

1. Clone oofem

2. Create a repro on github

3. push oofem develop to the repro

4. clone repro on github

5. set up upstream so that changes from oofem develop can fetched to the github clone.

Is there a better way to do this?

  • From: Gothenburg, Sweden
  • Registered: 08-09-2009
  • Posts: 1,419

Re: What about using distributed version control (GIT) ?

Well step 5. is could be the only tricky part. Borek prefers that you do a rebase from the developer branch rather than merging.
That is, doing

git pull --rebase developergit master

where developergit is the name of the git repo on oofem.org. Probably named "origin". Check with the command "git config -l"
Its possible to set "--rebase" on by default as well. http://blog.aplikacja.info/2010/11/git- … y-default/
(the wiki should probably be updated a bit to include this).

Although I think if someone does a merge, which is probably slightly easier (and almost a must if there has been large changes) its not the end of the world.

15 Reply by bp

  • bp
  • Administrator
  • Offline
  • From: Prague, Czech Rep.
  • Registered: 02-03-2007
  • Posts: 1,047

Re: What about using distributed version control (GIT) ?

Personally, I see the step 2+3 renundant, as you can directly clone oofem develop into your local repository and merge  the contributions of  your collaborators, either by giving them push access via ssh, which is really simple to set up (if you run linux) or by merging changes by yourself. If you prefer the github interface, then it is ok.

bp's Website

  • gustel
  • Senior Member
  • Offline
  • Registered: 16-04-2007
  • Posts: 102

Re: What about using distributed version control (GIT) ?

OK, I agree that the github steps are not really necessary.

Another question: As much as I understood, there is now a master and develop branch within git. In the last days changes have been made to the develop branch and others to the master branch.
I thought that I would be OK to follow only the develop branch. However, I do not seem to get then the updates from the master branch. Should not changes be always made first to the develop branch?

17 Reply by bp

  • bp
  • Administrator
  • Offline
  • From: Prague, Czech Rep.
  • Registered: 02-03-2007
  • Posts: 1,047

Re: What about using distributed version control (GIT) ?

Sure, the changes should be made to develop branch. It is true, that milan has made change in master branch, because he did not followed the documentation. Only the devel branch should be used to push development changes.

bp's Website

18 Reply by bp

  • bp
  • Administrator
  • Offline
  • From: Prague, Czech Rep.
  • Registered: 02-03-2007
  • Posts: 1,047

Re: What about using distributed version control (GIT) ?

It seems that nobody reads the wiki documentation. I have proposed to have two branches: develop and master. All new code was supposed to come to develop branch, while master branch was supposed to be for stable releases.
Now I can see that most of you commit the work into master branch, unfortunately there are contributions both in master and develop branch right now.

So to resolve this issue, I propose to leave master for development, and I will create a new branch, called stable, into which the stable releases will be merged from master(development) branch.

ok?

bp's Website

  • From: Gothenburg, Sweden
  • Registered: 08-09-2009
  • Posts: 1,419

Re: What about using distributed version control (GIT) ?

Sorry about that Borek.
I thought I had it set to push towards the development branch when I pushed the CMake scripts.

I'm fine with the change if you think that will cause less problems.

20 Reply by bp

  • bp
  • Administrator
  • Offline
  • From: Prague, Czech Rep.
  • Registered: 02-03-2007
  • Posts: 1,047

Re: What about using distributed version control (GIT) ?

ok, changed the repo structure, merged develop branch to master and deleted develop branch.
So for now:
- master branch for development
- stable (not yet created) for tracking releases. I will create this branch once we will have new release version.

Borek

bp's Website

  • From: Gothenburg, Sweden
  • Registered: 08-09-2009
  • Posts: 1,419

Re: What about using distributed version control (GIT) ?

I'm actually experiencing some troubles because of rebasing now. Seems like i made some newbie mistakes with rebase.
I have managed to leave my github repo in a messed up state because due to rebasing oofem.org (i got duplicated commits followed by a merge)
I tried rebasing on oofem.org again to salvage it, but it gets me tons of conflicts, so just dropping it and starting fresh from oofem.org again seems like the easiest choice.


The rebase workflow only allows for a single master repo. It is great for rebasing a few local commits before a git push.
But if you ever work through a secondary repo (for me i have a copy at home, at work, and on github), you can be pretty sure that you'll experince some technical difficulties with rebase, unless you are really really careful.

Especially, for me as a "Lieutenant", I would have preferred if people based their contributions on my code (if they want me to pull the changes), and I'll bring that in to oofem.org eventaully.
Rebasing a public repo will mess things up for whoever who might want to clone that.
I guess I could/should clone the repo, branch it, work on that branch for a while, without touching master, and rebase that (private) branch on master occasionally (and when i to rebase it, I have to be quick and push to oofem.org right away, to keep my master branch from ever rebasing)
And If I ever pull from someone who wants to contribute, I have to push to to oofem.org right away. If another commit slips inbetween, a merge is the only choice left (otherwise I would have to rebase others codes, in a public repo)