Welcome, Guest. Please login or register.

Pages: [1] 2
Print
Author Topic: Proposal: Switch to Git  (Read 10171 times)
aspidites
Community member

Posts: 29


View Profile Email
« on: November 27, 2010, 07:01:20 PM »

For the official answer as to the advantages of git over svn, see this article on the official linux kernel website.

My main argument for the switch is that it makes contributing much easier. Compare (what I understand to be) the work flow for svn vs git:

SVN
1. contributor writes some code
2a. if contributor is a main dev, he can immediately push to svn, thus his local branch is mostly always up-to-date
2b. if contributor is not a main dev, he has to generate a patch
3a. contributor need only 'svn pull' to be up-to-date, losing no changes since he has commit access
3b. once a patch is created, contributor needs to open a ticket, add the patch to a ticket, and optionally (read: preferably) create a thread here in the forums)
4b. contributor must wait for his patch to be accepted before working on the same bit of code, else create another patch that supercedes it. Otherwise, he loses whatever changes haven't been merged into trunk. Alternatively, he can work on another piece of source to avoid this.

GIT
1. contributor writes some code
2a. if contributor has access to repo, he can push immediately
2b. if not, he can at least commit local changes so he doesn't lose anything.
3a. if using a frontend like gitorious or github, he can request a merge/pull.
4a. if your request isn't accepted, you can still pull from the main branch, assuming their arent any conflicts.


The key point for me is being able to work on different pieces of code without risking losing any of my contributions, and also the speed at which patches can potentially be applied.

With SVN, patches have to be applied manually, but with git, a simple press of an accept button will do so.

FAQ

As people respond to this topic, I'll fill the FAQ section with rebuttals.
« Last Edit: November 27, 2010, 07:08:26 PM by aspidites » Logged
Q_x
Admin
Community member

Posts: 553



View Profile
« Reply #1 on: November 28, 2010, 01:38:10 PM »

I'm not a coder, so I'd gladly never see version control software, really. They deal badly with binary data, plus they are making a lot of mess on my end. They are unimportant, as I don't collaborate eg. when drawing inventory icons.
How I see it:
Pros:
1. There are two main sites now: Github and Gitorious. They are offering free space, unlimited.
2. If comiting code and using Sparkleshare will be not interfering - we will be in heaven.

Cons:
0. Will take time and effort to migrate. Lot of it from our perspective, even when using UH experience, knowledge and good advices.
1. Local commiting and later including changes into "central branch" will not be as easy and straightforward as it is now.
2. We will have to port some stuff there, like tickets.
3. Keeping local history makes a lot of bloat.
4. Even moving files inside the repo seems to be complicated.
5. we will have to rewrite some docs.
6. Distributed code versioning is more complicated: to set it up, to explain, and to use it.

Sidenote: I will never, ever use bzr for my project, nor join a project that uses it. Instead of two possible actions, that are working like upload and download in general, I suddenly have 5, and if I mess order of any of needed steps - I'll end up with seriously messed up things that will take some real time to untangle.
Logged

aspidites
Community member

Posts: 29


View Profile Email
« Reply #2 on: November 28, 2010, 06:26:22 PM »


Cons:
0. Will take time and effort to migrate. Lot of it from our perspective, even when using UH experience, knowledge and good advices.
1. Local commiting and later including changes into "central branch" will not be as easy and straightforward as it is now.
2. We will have to port some stuff there, like tickets.
3. Keeping local history makes a lot of bloat.
4. Even moving files inside the repo seems to be complicated.
5. we will have to rewrite some docs.
6. Distributed code versioning is more complicated: to set it up, to explain, and to use it.

Sidenote: I will never, ever use bzr for my project, nor join a project that uses it. Instead of two possible actions, that are working like upload and download in general, I suddenly have 5, and if I mess order of any of needed steps - I'll end up with seriously messed up things that will take some real time to untangle.

1. It will, because local committing is impossible right now. Using say, gitorious, a contributor would submit a merge request. If there are conflicts with mainline, they can either a) be handled as they are now, with the patch being applied manually, or b) a 3 way merge tool can be used to sort out the differences.
3. SVN keeps local history, so how will git be more bloated? Actually, comparing the trunk code as an SVN repo and GTI repo, the git repo was smaller (512MB vs 628MB)
4. In what way is "git mv src dest" more complicated that "svn mv src dest"?
6. More complicated, but only if you allow it to be. That is, there are definitely more features, but you need not concern yourself with all of them.


Original points 0, 2, and 5 are implicit, so not really worth arguing.
Logged
zenbitz
Community member

Posts: 1164



View Profile
« Reply #3 on: November 28, 2010, 07:20:38 PM »

I spend more time on the squishy parts of parpg and not the code, but I am a real-life programmer.
I have recently been converted to git - especially for os programming.

However, I think it's an awful idea to unilaterally switch... we can't afford to annoy even one contributing programmer, so pretty much we shouldn't be switching.

HOWEVER, I think it would be totally reasonable to use git-svn to keep a local git repo and push back to svn.   Also, svn is probably a little better for "content" (binary files that don't change much, or are almost never edited by more than one person).

Logged

We are not denying them an ending...
We are denying them a DISNEY ending - Icelus
aspidites
Community member

Posts: 29


View Profile Email
« Reply #4 on: November 28, 2010, 07:57:48 PM »

Also, svn is probably a little better for "content" (binary files that don't change much, or are almost never edited by more than one person).

Latest versions of git (1.5.3 I think) allow for submodules to solve this.

I'll do more research into git-svn though.

I will say, however that the current patch submission process is a bit annoying.

Update:
Githup also has support for svn: https://github.com/blog/626-announcing-svn-support

Basically, it would be a git repo, but you could use svn commands.
« Last Edit: November 28, 2010, 08:00:08 PM by aspidites » Logged
mvBarracuda
Admin
Community member

Posts: 1308



View Profile Email
« Reply #5 on: November 28, 2010, 09:54:37 PM »

I'm not opposed to switching to git per se, but I would like to hear how the other programmers (Technomage, Beliar, Domtron) feel about it.

My main priority in this case is, that Trac is essential to the project workflow at this point. There are Trac hacks to integrate the software with Git, while SVN is officially supported out of the box. Github doesn't offer Trac support AFAICT. Our current host (codesion.com) offers git support, but I'm not sure if they offer Trac integration for Git as well. But I'll find that one out soon.

So in case we can get Trac working with Git and if the other programmers feel that the change is worth the effort it takes to make it, I'm all for it.

EDIT: As pointed out by Zenbitz, using git-svn locally would be another option:
http://www.kernel.org/pub/software/scm/git/docs/git-svn.html
« Last Edit: November 28, 2010, 10:03:47 PM by mvBarracuda » Logged
Technomage
Admin
Community member

Posts: 80



View Profile
« Reply #6 on: November 28, 2010, 11:08:00 PM »

+1 for git-svn. I've used it, it works, and it works well. Basically you setup a local git repository and connect it to a remote svn repository. You track all local changes in the local git repository, and then commit the changes to the remote svn repository whenever you feel like it. git-svn may provide some more advanced features, but I've never used them.

git-svn would solve the local changes issue, but there is still the issue of submitting patches. Git makes submitting patches easy for contributors without version control access since they can request a merge of their local branch and Git handles the patch process automatically, so +1 for git there. git-svn may have some method of merging local git branches with the main svn branch, but I suspect that would depend entirely upon the web software hosting the svn repository.

I have no experience in managing remote repositories, so I can't comment on the difficulty of changing version control systems. I suspect that git and svn have enough interoperability to make the process fairly easy, but a week or two or chaos will almost certainly ensue regardless.

In the long run git may be a good choice since it makes it easier for contributors, but we may want to wait until after techdemo2 to make the switch. If we're going to switch the sooner the better, though.

Just for the record, I concur with Q_x that bzr is a horrendous version control system and not worth the trouble. I don't have much experience with mercurial, but my impression is that it is very similar to git but a bit younger and less stable.

EDIT:
It appears that git-svn can be used to convert an existing svn repository to a git repository with minimal fuss, so the transition might not be as bad as I first predicted. GitHub also has an svn "import" feature if we wanted to use GitHub hosting.

Here are some tutorials and thoughts about switching from svn to git:

http://codesanity.net/2010/03/making-switch-svn-git/
http://pauldowman.com/2008/07/26/how-to-convert-from-subversion-to-git/
« Last Edit: November 29, 2010, 12:05:21 AM by Technomage » Logged

"There are more atoms in the period at the end of this sentence than you can count in a lifetime." Science is awesome.

mvBarracuda
Admin
Community member

Posts: 1308



View Profile Email
« Reply #7 on: November 29, 2010, 06:40:25 AM »

Just did some research and I couldn't find a free (of charge) git hoster who offers Trac <> Git integration at this point. Check out this list:
https://git.wiki.kernel.org/index.php/GitHosting

Our SVN & Trac host codesion.com currently offers git hosting in beta status. Unfortunately there is no Trac integration at codesion at this point, but according to this article they're working on it:
https://help.codesion.com/View.jsp?procId=89165431a001a745cab96274dbd4d2b8

I guess "external ticket integration" basically means Trac ticket support?

I'm quite fond of working with Trac right now and some of its features feel essential to me, especially ticket integration. But also the sourcebrowser and milestone planning are great tools. My personal proposal is to stick to SVN for the time being and developers could use git-svn on their machines to be able to commit to local repositories. As soon as codesion.com offers Trac <> Git integration, we could switch. If somebody knows a free Git host that offers Trac integration, I would consider switching to a different host, but we would have to keep in mind that we might can't export our current Trac data (tickets, milestones) and import it into a different Trac repo so there would be quite some effort needed to recreate this information.

EDIT: I've filed a support ticket / question at the codesion.com support forums and asked them about their plans and timeframe for git <> Trac integration. Unfortunately the forums can only be accessed by devs who are logged into their codesion.com account. For everyone who already has a PARPG developer account, you can view the thread here:
https://help.codesion.com/Question.jsp?id=ea01485919ca0138111dd05315c901f3

For the others, I'll post their answer to this thread as soon as their staff replies.

EDIT 2: As the question came up on IRC: we currently get hosted for free at codesion.com, based on their free open source hosting plans. As we already invest our free time into the project, I'm not keen on the idea to pay for hosting; I'm still in college and money to spend is sparse on my side :-(

EDIT 3: As brought up by aspidites: we could also go down the route of hosting trac and a project management tracker at different providers. E.g. we could use github in combination with https://www.hostedredmine.com/. AFAICT hostedredmine supports external git repositories, though further investigation is needed to actually confirm that. Personally I would still prefer a solution that is hosted by one provider, that would make the whole admin job easier in case problems arise and it's hard to tell which provider would be responsible for addressing them.

Anyway, I'm glad that a lot of you contribute to the discussion so keep the feedback coming. Switching such an important part of the project infrastructure is quite an important step, so we should take our time, evaluate the options we have, discuss what suits our needs best and make the step after that.
« Last Edit: November 29, 2010, 01:38:46 PM by mvBarracuda » Logged
timf
Community member

Posts: 1


View Profile
« Reply #8 on: November 29, 2010, 07:53:39 PM »

Akiri Solutions has an integrated trac + git repository solution combined with an easy-to-use UI (web-based instead of cryptic console commands):

   http://www.akirisol.com

The git repository and issue tracking are hosted in a virtual machine you run on your own server, and access to that system is made available to the developers directly through your network or optionally, through the Akiri web site, if enabled.

It is a commercial solution, though special rates are available for open source projects.
Logged
mvBarracuda
Admin
Community member

Posts: 1308



View Profile Email
« Reply #9 on: November 29, 2010, 07:57:13 PM »

Fair enough tinf :-)

As previously expressed though: I would prefer to a free of charge solution, simply because we already invest our time for free.
Logged
zenbitz
Community member

Posts: 1164



View Profile
« Reply #10 on: November 30, 2010, 12:31:00 AM »

my recommendation is to take it slow.   People who are familiar with git can just git-svn and poke around for a while.  Merging patches is certainly no *worse* than current.   They can talk to other developers ... maybe when no one remembers how SVN works any more we can just do git.
Logged

We are not denying them an ending...
We are denying them a DISNEY ending - Icelus
mvBarracuda
Admin
Community member

Posts: 1308



View Profile Email
« Reply #11 on: November 30, 2010, 12:39:04 AM »

my recommendation is to take it slow.   People who are familiar with git can just git-svn and poke around for a while.  Merging patches is certainly no *worse* than current.   They can talk to other developers ... maybe when no one remembers how SVN works any more we can just do git.
Sure zenbitz. As previously said: switching an important part of the project infrastructure should be something that is discussed in detail before making a hasty move. Nevertheless it doesn't hurt to evaluate our options, try to find the best one for us. And once we have found an option that would work for us, we can always make the step to git; it's not likely that our prefered host will suddenly vanish in case we don't switch to git right away.

Anyway, more findings on git & Trac: Nihathrael from Unknown Horizons pointed me towards Assembla.com, that offers Git support with an integrated ticketing system (prolly based on a forked Trac).

Anyway, I created an account for testing purposes, but this turned out to be a bit complicated. Tried to create a project space for PARPG about 10 times before it finally worked. Previously it simply complained that "There was an error saving your space". Anyway, after it finally worked I could take a closer look at the ticketing system they offer. It looks like a modified Trac version that seems a bit simpler to use at the cost of less flexibility and options.

There are two more drawbacks I've found. Maybe their servers are currently just busy and that's not the norm, but their website felt really sluggish and unresponsive today. I had to wait for about 5-10 seconds for every interface link I clicked on. They prolly have two quality class hosting, leaving the free hosting plans with the slower servers. The main reason I would prefer to find a different git host is that Assembla just offers 2GB of project space. If we just host trunk/game in Git, that's not a problem but as soon as you want to have all assets in the same version control system, it will get nasty. Once we add new graphical assets to the game and bring the source versions (models, textures) under version control as well, the 2GB of space prolly won't be enough in the long run. It doesn't look like they offer any special hosting plans for established projects so you can't seem to get more than 2GB for free.

Another aspect is chosing a git host that has an established reputation as open source host. This way it would be far more likely that somebody stumbles over the project and decides to take a closer look and might even get involved in the development of PARPG later. Gitorious seems to be open source centered, while github provides closed source hosting as well.

So my personal proposal is: try out gitorious and sign up at hostedredmine.com to have git <> redmine (ruby-based Trac equivalent) integration. This way we have unlimited space for the project at gitorious, project management features with version control integration through redmine and we would be hosted at an well-established open source git host.

I'm still open to suggestions for alternative Git & Trac (or alternative similar project management tools) hosts. I'll check out Gitorious and hostedredmine in the meanwhile.
Logged
mvBarracuda
Admin
Community member

Posts: 1308



View Profile Email
« Reply #12 on: November 30, 2010, 06:29:44 AM »

And here comes another update from my side:

I had a look at Github, but it unfortunately just offers a rather basic bugtracking solution right now. You just have a title and a description field for tickets, which is insufficent for PARPG IMHO. Gitorious provides no bugtracking solution at all at this point, at least I couldn't find one.

hostedredmine.com just supports Trac integration with SVN repositories, not with Git repos. Codesion.com considers to add git <> trac integration at some point but it's pretty much still in brainstorming stage so we shouldn't count on seeing support for it soon. My feature request can be found here: https://help.codesion.com/Question.jsp?id=ea01485919ca0138111dd05315c901f3

You can vote for this feature request if you got a codesion account (you got one if you have SVN access). Voting might help to show them that there's a demand for the feature: https://help.codesion.com/Idea.jsp?id=aa82e68e7cfd71ecb628a1ebb03ce787

I've been talking to Technomage on IRC and to me, there is quite a bunch of essential functionality that trac provides: timeline support; changeset browsing; post commit hook support for modifying tickets; sourcecode browsing; ticket integration for changesets, source files, revisions. As we couldn't find a free of charge host who offers Trac <> Git integration for open source projects, we might want to reconsider the situation.

Working in local branches can be achieved by using git-svn. The other remaining hurdle of the current workflow is the patch submission process. My personal proposal is to rather stick to SVN as it offers great Trac integration and reevaluate switching to git whenever there are free of charge hosting plans available that offer Trac <> Git integration, either by codesion.com or a different host.

I've created another thread for discussing how to improve the current patch submission process:
http://forums.parpg.net/index.php?topic=759.0
« Last Edit: November 30, 2010, 06:35:33 AM by mvBarracuda » Logged
mvBarracuda
Admin
Community member

Posts: 1308



View Profile Email
« Reply #13 on: December 02, 2010, 04:38:09 AM »

More food for thought that might serve as inspiration when we revisit the topic at some later point: Python PEP on choosing a dvcs:
http://www.python.org/dev/peps/pep-0374/
Logged
mvBarracuda
Admin
Community member

Posts: 1308



View Profile Email
« Reply #14 on: January 24, 2011, 05:40:40 AM »

I've added a distributed version control user story to the product backlog: http://parpg-trac.cvsdude.com/parpg/ticket/286

We should try to answer some open questions in a spike first before we actually commit to switching to a dvcs in an (infrastructure) sprint:
1. What are our hosting options for using a dvcs? (self hosted vs 3rd party hosting)
2. How well do dvcs integrate with Trac and do 3rd party hosts offer Trac integration?
3. If no 3rd party hosts offers Trac integration, what Trac functionality is essential to us and how would we replace it if we would switch to a dvcs without Trac integration?
4. Where should ingame & raw assets reside in a dvcs? Are there architecture issues that prevent putting a large number/size of assets (binary files) into a dvcs?
5. Are there well established GUI clients for the dcvs for all platforms we target?

These question can be explored in the existing work in progress dvcs proposal that resides at the wiki:
http://wiki.parpg.net/Distributed_version_control_software

We've also created a related proposal for Trac evaluation to adress point #3 mentioned above:
http://wiki.parpg.net/Trac_evaluation
Logged
Pages: [1] 2
Print
Jump to: