[James Ross]

Switching to a distributed version control system will enable developers to more easily create, share and collaborate on new features. Hosting the Git repository on Launchpad will enable integration with the bug/blueprint tracking and access controls already in place. Together they will enable new code to be created and shared (and maybe built) with no management overhead, while still enabling desired contributions to be merged in to the official code.

Blueprint: https://blueprints.l...it-on-launchpad

I think it's high time we kicked off the discussion about using distributed version control, and it seems Launchpad's support for Git is now good enough for us to start doing that. Because of the nature of distributed version control, we can have a "mirror" of the code repository on e.g. GitHub if people want, but I don't want to split the bug/feature tracking into multiple places so Launchpad will continue to be the only place to report bugs/log features.

[gpz]

I think this change is welcome. Do I understand right, that the svn server will be stopped?

[James Ross]

gpz, on 27 November 2015 - 08:04 AM, said:

I think this change is welcome. Do I understand right, that the svn server will be stopped?

Correct. The entire history will be converted/kept so there will be no need to keep it.

[roeter]

Well, over the long years in my work I have seen many tools, including a fair handfull of software configuration tools, being introduced with many such similar promises of much easier use and much better work etc. And after lots of work to change everything and a fair time to get used to the new tooling, such promises, obviously, were never fullfilled. Not to put too fine a point on it : just before I retired, SVN was introduced at my work, using pretty much the same arguments as being aired here to introduce GIT. Also, I have a bit of a nagging feeling we're changing to provide a solution for a problem which does not really exist.
So, please forgive me if I am not immediately jumping and dancing for joy at the idea of this switch. But who am I to keep you from your holy grail?
Just a word of warning, though. When I first joined OR I was told to submit code in SVN - like that, without any further information as to how or what. So I did - and made mistakes, and even if I did not make mistakes I did not do it the way I was supposed to. It took some time to find out what that way actually was.
So, if you want this change to go smoothly, my advice is to provide very clear and short guidelines on what to do - half a page of single-line steps should do the trick, one set for developers, one for users. Don't just send us a link to the documentation - that usually starts with a lot of giberish on how good and easy the tool is, and then gives you 784 alternatives for just the first command. And anyway, documentation is for dummies - we, the experts, can do things by intuition, we don't need a manual. Until the whole thing collapses right in front of our eyes - but that's not our fault, just shabby software.
Half a page of clear rules might just tempt us to read it. Otherwise, you could well be surprised (and not pleasantly) by the daft errors people can make. Don't think the software will prevent such errors. I spend my working live in the software test department, our job was to show that software did not meet its requirements, including protection against incorrect input. We rarely failed.
Just remember Murphy.

Regards,
Rob Roeterdink

[James Ross]

roeter, on 28 November 2015 - 03:46 AM, said:

So, please forgive me if I am not immediately jumping and dancing for joy at the idea of this switch. But who am I to keep you from your holy grail?

That's understandable; one of the key things we can enable by using distributed version control is anyone can publish their changes without much effort (certainly compared to Subversion). A bit like branches in Subversion could be, but aren't due to access controls and in our case a weirdly set up Subversion server. That's another thing we can remove - the weirdness of our Subversion server set-up and the delays in adjusting access controls due to having to go via a 3rd party.

This means that, for example, both you and I can publish our own experiments, changes and improvements on our own terms - with or without any intention of them going in to the main OR program. And if they do want to go in to the main OR program, merging them in is easier to do because this is actually supported by Git (rather than just a .patch file and praying it works).

roeter, on 28 November 2015 - 03:46 AM, said:

So, if you want this change to go smoothly, my advice is to provide very clear and short guidelines on what to do - half a page of single-line steps should do the trick, one set for developers, one for users. Don't just send us a link to the documentation - that usually starts with a lot of giberish on how good and easy the tool is, and then gives you 784 alternatives for just the first command.

Don't worry, I've experience teaching Git to people at work and I am more than aware of the need for a good intro - the documentation for Git can be terrifying, but there is a good alternative, the Git Book, which is definitely recommended reading and I'll produce an intro that includes how the Git commands relate to Subversion, and obviously answer any questions.

[Lindsayts]

For what its worth, Git was originally developed as a version system for the Linux kernel and it still uses it, this is why the support for independent branchs is so good.
It came about after the main Linux devloper Linus Torvadis (the guy the originally wrote the Linux kenel and still looks after it) changed its version control system to a commercial product. As Linux is all open source, this created a real serious howl of protest. After a long and _________VERY___________ heated debate, Git was produced and as there is a number of major LInux kernel developers each with his own version of the kernel support for such things was included from the beginning.

For info on Git see,https://git-scm.com/about

Lindsay

[Csantucci]

I have Rob's concerns too and fully agree with his post and his request about a short how to do essentials page.

[gpz]

James,

I would just let you know, that the .gitattributes line

* text=auto

causes all sort of problems for me, both with my long standing own git OR repository, and with a fresh clone of your https://git.launchpad.net/~twpol/or one. I have to comment this line out, otherwise git recognizes many files as modified, that were not; these files cannot be committed, because at commit time git filters them out as unmodified ones, but afterwards they are still listed as modified; rebasing a branch onto other doesn't work because of this, since git denies doing that with existing working tree modifications, but these mods are false positive, no stashing or committing is possible. Etc... No matter how I set autocrlf option, I couldn't find a working configuration other than commenting this line out.

[James Ross]

gpz, on 30 November 2015 - 01:06 AM, said:

I would just let you know, that the .gitattributes line

* text=auto

causes all sort of problems for me, both with my long standing own git OR repository, and with a fresh clone of your https://git.launchpad.net/~twpol/or one.

Yes, this is a problem with the git-svn plugin, which puts everything in to Git exactly as it is in Subversion, which means you have your repository full of CRLF even though Git prefers just LF. The .gitattributes files are going to be great when we actually convert the repository properly instead of using the plugin though. For now, the way you use the git-svn repositories is to put "* -text" in to .git\info\attributes which overrides .gitattributes.

[gpz]

Thanks, it works perfectly!

[James Ross]

I've started writing a specification for the Git proposal, which is mostly the introduction to Git stuff and details of how I believe the process will work.

I would appreciate it if you could comment on the document (requires a Microsoft account) or in this thread. In particular, I will be looking to answer any questions raised by editing the document, so that it provides the best information for the switch.

[wacampbell]

This is good to see. We have had the kind cooperation of a 3rd party to manage our SVN server for many years, but its time that we offload that task. A server change at the very least is in order, but now that OR is open source, we have the option to use Git services from Launchpad or others and that makes sense.

I am not familiar with Git, although I know it is widely praised. I am curious about its ability to pull and push changes. Is there magic here in fixing up coding conflicts that usually come with a merge, or is it just a line by line text merge of the code as we might have seen in SVN?

[Csantucci]

James,
first of all thank you very much for your document. It's exactly what I - that never used git - needed. I hope I will able to replicate the full flow.
Personally I was comfortable with Tortoise, but I understand there can be advantages here.

[James Ross]

wacampbell, on 27 March 2016 - 06:44 AM, said:

I am curious about its ability to pull and push changes. Is there magic here in fixing up coding conflicts that usually come with a merge, or is it just a line by line text merge of the code as we might have seen in SVN?

The pushing and fetching do not involve any merging themselves, as they're simply replicating one set of commits/history in to another repository. If you and I both make commits on branch A, when I get your commits locally I will have a divergent history. Git provides multiple options for resolving that:

• If my changes have not yet been shared, I have the option to "rebase" - which is effectively replaying my work on top of yours, so it becomes linear.
  
• In all cases, I have the option to "merge" - which is much the same as in Subversion, taking both histories and trying to reconcile their unique differences.

In both cases, conflicts can (and do occasionally) arise. Resolution is identical to Subversion, and if you use TortoiseGit you'll have exactly the same UI for it too. :)

I believe that Git can avoid merging and do better at it when it does happen for two reasons:

• Its history of commits and their parents is very precise and correct, where as Subversion has been lacking quite badly in this area - so Git has better information about the ancestry available.
  
• Its default merge algorithm can cope with multiple common ancestors, using the "recursive" merge strategy (the default), for when you've already done some merging and are re-merging branches and that kind of thing.

Git can also use other merge strategies and even has a few diff algorithms that can be selected in cases where the default "myers" is not working well. That flexibility is something I've not yet exploited, but is probably good to have in the toolkit.

[disc]

When will the switch happen?