[marklittle]

None of our projects should be moving completely off svn. If that is the case then we have a problem. Stop.

[dmlloyd]

I'm somewhat boggled by this, as we have many projects which have moved completely off of svn, and we have many projects which were never on svn in the first place.  Like AS7 for example...

There's really no upside to svn - if it's a knowledge issue, there are many people who can help with the learning curve.

[jason.greene]

Almost all JBoss projects have moved completely to git (no svn). This includes

1. JBoss AS
   1. Jandex
   2. DMR
   3. Threads
   4. VFS
   5. Modules
   6. MSC
   7. Invocation
   8. Console
   9. Classfilewriter
   10. EJB Client
2. Switchyard
3. Hibernate
4. Infinispan
5. JGroups
6. RichFaces
7. Weld
8. Seam
9. Drools
10. Modeshape
11. Arquillian
12. Shrinkwrap
13. Errai
14. Remoting
15. XNIO
16. Marshalling
17. Byteman
18. Torquebox
19. BoxGrinder
20. Savara
21. Scribble
22. Some Gatein side subprojects

Projects not moved but thinking about moving:

1. RestEASY
2. Hornetq
3. Gatein main project
4. JBoss Tools

[jason.greene]

This is just my opinion, but the strongest and most convincing reason to move JBoss Transactions to GIT would be a stricter quality / review process. This is because GIT lets you do the following:

1. Prevent changes from being merged until they are widely reviewed by everyone and finally approved by the maintainer(s). This is usually one person but can have some redundancy if need be
   1. All changes have multiple "eyes" on them
   2. Testing is ran by multiple parties
   3. Everything implicitly gets an architectural and design review
2. Isolate and test individual features separate from the main tree. This means that regressions can be tested and caught before they are ever in the public master branch. Note that unlike SVN these branches are relatively easy to sync and can be long running,

In addition it's easier to track down the source of a problem in the event that the above processes fail. Git has a command called "bisect" that automates an O (log N) search through your commit history for the regression. So the process for finding the failure becomes

1. Write a test case that shows the failure
2. Start a bisect from the last known good commit
3. Execute the test, and upon success call "git bisect good", failure call "git bisect bad". This can be easily scripted
4. Have a cold beer

Some other powerful benefits are:

1. Do work on an airplane (no server required) [also useful when JBoss.ORG goes down]
2. Quickly switch branches, make changes, create new branches etc (much better productivity)
3. Cryptographically secure history. Every change is a SHA1 of the change + commit + past change. Therefore, it is near impossible to hack the code/history of a git repo. To do it you have to change the SHA1s, and once you do that all other copies in the world will show yours is a fake.
4. Extra redundancy (everyone has a copy), and easier migration (quick/easy to copy)

The drawbacks to moving to GIT are

1. Maintaining a GIT repo requires a lot of GIT knowlege (the person(s) in charge of approving / pushing changes). This can lead to folks transitioning that are unfamiliar with it having a hard time. Before moving any project of this nature to GIT, you should get to know it, and read some of the material and ask for help from others.
2. Contributers that are used to svn or cvs will have to learn something very different. Much less knowledge is needed than 1) but it's still enough that it will require ramp-up to those unfamiliar with it
3. If it aint broke.....

[jason.greene]

BTW I recommend taking an hour to watch Linus' original video on this from 2007. This was way before it was widely accepted.

http://www.youtube.com/watch?v=4XpnKHJAok8

[marklittle]

I'm somewhat boggled by your response, but then maybe we're coming at this from different angles. Let me try to make it clearer: when I agreed to support moves to git it was on the understanding that all project moves would be done with the clear understanding that productisation branches would still be maintained in svn. I know that that is happening for some projects. I'm hoping that it's happening for all projects. That link back to svn is the one that cannot be broken.

David Lloyd wrote:

I'm somewhat boggled by this, as we have many projects which have moved completely off of svn, and we have many projects which were never on svn in the first place.  Like AS7 for example...

There's really no upside to svn - if it's a knowledge issue, there are many people who can help with the learning curve.

[marklittle]

Your drawback number 3 is the interesting one ;-)

This may certainly be something to consider for TS 5. I'm still unconvinced about the existing 4.x code though.

[marklittle]

Seen that already and we're arranging for online training sessions too. Don't get me wrong: I like git and understand pros and cons (roughly). But as always for the next 6 months my concern is timing and whether this is really the right thing to do for the 4.x series now. I don't see this any different to when we moved TS from cvs to svn: we left older versions in cvs that we touched rarely and new development continued in svn.

Jason Greene wrote:

BTW I recommend taking an hour to watch Linus' original video on this from 2007. This was way before it was widely accepted.

http://www.youtube.com/watch?v=4XpnKHJAok8

[jason.greene]

Mark Little wrote:

Your drawback number 3 is the interesting one ;-)

This may certainly be something to consider for TS 5. I'm still unconvinced about the existing 4.x code though.

Yeah there realistically will be an impact for doing the conversion. It does only take a day to convert and move the code but then you also need to:

1. Decide on a workflow/process to use with Git.
2. Decide who the maintainer(s) will be
3. Talk to JBoss.ORG on getting fisheye set up to point to it
4. Consider using the Git workflow in JIRA
5. Get everyone up to speed on using Git
6. Update all websites and artifacts to point to the new repo
7. Give the product team a heads up that the switch occured

What you describe for TS5 is what we did for AS 7. We left the old pre-7 codebase in subversion since moving it to git wasn't by any means an urgent matter. Although in our case the implementation was very different so the history wasn't as important.

I would recommend having an answer to all of the open questions above before actually planning and doing the conversion.

[jason.greene]

Mark Little wrote:

Seen that already and we're arranging for online training sessions too. Don't get me wrong: I like git and understand pros and cons (roughly). But as always for the next 6 months my concern is timing and whether this is really the right thing to do for the 4.x series now. I don't see this any different to when we moved TS from cvs to svn: we left older versions in cvs that we touched rarely and new development continued in svn.

Definitely understand. I was just offering extra information and my unsolicited opinion that it would probably be helpful long term. It was mentioned earlier but you can also use git as an svn client as an interim solution if someone is really wanting some of the capabilities git offers. I maintain a git mirror for mojarra (uses svn) for example.

[marklittle]

Yes, absolutely agree.

Jason Greene wrote:

I would recommend having an answer to all of the open questions above before actually planning and doing the conversion.

[marklittle]

OK, that's interesting. As a slight aside, Mic Neale and I were talking about svn on git yesterday

Jason Greene wrote:

Mark Little wrote:

Seen that already and we're arranging for online training sessions too. Don't get me wrong: I like git and understand pros and cons (roughly). But as always for the next 6 months my concern is timing and whether this is really the right thing to do for the 4.x series now. I don't see this any different to when we moved TS from cvs to svn: we left older versions in cvs that we touched rarely and new development continued in svn.

Definitely understand. I was just offering extra information and my unsolicited opinion that it would probably be helpful long term. It was mentioned earlier but you can also use git as an svn client as an interim solution if someone is really wanting some of the capabilities git offers. I maintain a git mirror for mojarra (uses svn) for example.

[paul.robinson]

Mark,

Let me try to make it clearer: when I agreed to support moves to git it was on the understanding that all project moves would be done with the clear understanding that productisation branches would still be maintained in svn. I know that that is happening for some projects. I'm hoping that it's happening for all projects. That link back to svn is the one that cannot be broken.

By this do you mean that going forward all *new* productization branches must be maintained in svn, or do you just mean that we need to keep the existing ones in svn?

I'm assuming you mean the former....

Given that productization branches would be baked in the (git based) community first, we would need to port from git to svn whenever we create a maintenance branch. This would be an additional overhead that needs to be considered. Also, is the migration path from git to svn as smooth? Does anyone actually do this?

Mark: can you explain the reasoning for keeping product on svn? This should help us understand if a compromise/hybrid approach is possible.

Thanks,

Paul.

[marklittle]

Our productisation teams have well defined processes by which they obtain sources and commit patches back upstream. Red Hat prides itself on providing excellent (long term) support to our customers for the open source products we provide. As such, anything we do in the community needs to tie into that.

Mark: can you explain the reasoning for keeping product on svn? This should help us understand if a compromise/hybrid approach is possible.

[tomjenkinson]

Just to say that this has happened. We kind of took the easy route and did a top skim of svn trunk and used this to seed our new repo. All existing branches for the 4.x and below will be maintained in svn. Narayana (i.e. trunk) will be maintained in git.

trunk svn is now locked read only in deference to: https://github.com/jbosstm/narayana, but the existing branches are working as they were, although of course it is possible to access the branches using git-svn if you prefer.

The website has been update with information on git: http://www.jboss.org/jbosstm/sourcecode - although to be fair, the most significant pointers to working with git are provided in the (linked on page) excellent "hacking on as7" article.

Note, I also created a separate repo for our quickstart/: https://github.com/jbosstm/quickstart. Again, this is as per AS7s approach.

Thanks to all for your feedback and suggestions on this! I will now raise this in the user forum where any issues with user documentation etc would probably be best placed.