Community
Participate
Working Groups
Here is an open item - and an offer for help - to move Jetty to git. Git is great, git makes you look good, git cleans your house for you, git will drive your car, git will hand you money when in a bind, and git will make your open sour project successful. If you actually would like to know what git is about, please consider googling it... Anyways. No rush, no pressure, a free hand to help when possible here, and there's a good window of opportunity to move to git after Helios. 1. Make sure the build would work with git 2. Assign this bug to webmaster for him to open the right folder 3. Do the migration itself 4. Educate everybody on git
what do folks think about targeting 7.2 for a git release?
Hmmm maybe. Does eclipse support git yet?
AFAIK yes it does and according to jason the maven tooling is up to snuff for our release process
For my 2c I'm not really in favour of changing to git for 7.2, mostly because there is still a lot of bi-directional merging going on between 8 and 7 in eclipse and therefore also in codehaus as well, so I don't think we really need the added complexity of dealing with different scms' as well. That said, if we reach a point where the merging is less intense, then I'm ok with it. But maybe we move jetty-8 to git instead - would make sense to do it for a major rev I think? Jan
ya, I hadn't considered the jetty8 effects of this really... Joakim, do you have any thoughts on that? I am thinking that we ought to wait until Gerrit gets allowed for general usage...then we can switch to that workflow for accepting patches and that sort of thing...i think it will be a great reason to switch once its active. below is the issue for that https://bugs.eclipse.org/bugs/show_bug.cgi?id=283749
Jetty7 and Jetty8 should exist in the same Git repo. After all, they are just different versions of the same codebase. Jetty7 would be refs/remotes/{origin}/master Jetty8 would be refs/remotes/{origin}/jetty-8 I don't fully understand nature of, or the worries about, the Codehaus and Eclipse bi-directional merging. But with the decentralized nature of git, a developer could have the following setup on their own machine (all within the same local git repository) refs/heads/master : (refs/remotes/{eclipse-jetty}/master = jetty7) refs/heads/jetty-8 : (refs/remotes/{eclipse-jetty}/jetty8) refs/heads/svn-jetty-6 : (refs/remotes/{codehaus-jetty-svn}/jetty6) This is possible, and I've done it for a few months myself. You can sync into and out of the pure git side and maintain an unconnected branch (meaning it has no common ancestor) on your local side with the git-svn checkout. Then you can cherry-pick certain patches between the 2 sides. (git merge -i) Course, the downside of this setup, is that since this is the same directory space on your own machine, you can't actively be developing in all 3 trees. So you would eventually split the git repo up some more, to suit your tastes. Such as cloning your local repo into a new directory (nice and fast too).
Actually the bi-directional syncing jan was referring to is just between 7 and 8 within eclipse, no outside repo's involved
If we were to do this: jetty -> jetty.git jetty-parent -> jetty-parent.git jetty-toolchain -> jetty-toolchain.git eclipse -> jetty-eclipse.git (or org.eclipse.jetty.eclipse.git?) jetty-wtp -> jetty-wtp.git (or org.eclipse.jetty.wtp.git?) jetty-admin -> jetty-admin.git Or perhaps jetty -> org.eclipse.jetty.git and toolchain to org.eclipse.jetty.toolchain.git regardless, I figure we ought to break it out largely like we have it now As for the jetty7 and jetty8 merging process, I think that would be nothing more then a 'git merge jetty7' or master or whatever the main trunk would be while your in a checkout of the jetty8 branch. We can either do the svn2git ourselves or we can have the web masters do it for us as on the bottom of the following page: http://wiki.eclipse.org/Git/Migrating_to_Git As for the release process, we have been assured that the maven tooling is in place for it to work and I could work on ironing that out and making sure it works correctly while doing the RC's of 7.2.0 while switching to git would also have the benefit of making forks at github easier to integrate with and we could stop the painful and error prone git-svn bridging. thoughts?
Jesse for the eclipse folder, in fact it turns out that it is all related to build and releases for OSGi. So if would go for: eclipse-releng (or org.eclipse.jetty.releng). We could also use 2 git repositories to reflect the 2 different builds there: - org.eclipse.jetty.releng.bundles - org.eclipse.jetty.releng.products I am looking forward to migrating to git.
Hugues, I don't follow what your looking for here.. are you referring to the naming behind jetty-bundles? For those interested, we are now actively plotting this migration now so chime in if you have thoughts...ideally we will pull the trigger on this in the next few weeks.
Also, this would be complete migration, no svn in the picture
What do folks think about splitting the jetty-osgi code out of the main jetty git repo? jetty -> jetty.git jetty-parent -> jetty-parent.git jetty-toolchain -> jetty-toolchain.git eclipse -> jetty-eclipse.git (or jetty-bundles.git) (or org.eclipse.jetty.eclipse.git?) jetty-wtp -> jetty-wtp.git (or org.eclipse.jetty.wtp.git?) jetty-admin -> jetty-admin.git jetty/jetty-osgi -> jetty-osgi.git
https://bugs.eclipse.org/bugs/show_bug.cgi?id=350188 I opened the migration thread with Community, tentatively scheduling the move for June 6th. This is the latest mapping: jetty -> org.eclipse.jetty.git jetty-parent -> org.eclipse.jetty.parent.git jetty-toolchain -> org.eclipse.jetty.toolchain.git eclipse -> org.eclipse.jetty.releng.git jetty-wtp -> org.eclipse.jetty.wtp.git admin -> org.eclipse.jetty.admin.git I opted for the o.e.j.git approach as that appears to be eclipse convention based on the projects on this list: http://git.eclipse.org/c/
Joakim had a nifty idea for the jetty7 and jetty8 branches. We will import over jetty7 and jetty8 and have effectively two branches, jetty-7 (or master as it was the trunk) and jetty-8. We take the jetty-8 branch and rename it to jetty-8-historical and then make a new jetty-8 branch and commit one mammoth patch taking the diff of jetty-7 git and jetty-8 svn branch. That should eliminate any hinky merge issues that might crop up from the jetty7 and jetty8 merging process up to this point. I was also thinking that since we are hot on the path of pushing jetty8 then if we are going to use a branch named 'master' then we ought to make that jetty8 and start doing development on jetty8, and merging back to jetty7 the work needed. That will kick the releasing of jetty 8 into high gear. thoughts?
*cough* July 6th
(In reply to comment #14) > Joakim had a nifty idea for the jetty7 and jetty8 branches. > > We will import over jetty7 and jetty8 and have effectively two branches, > jetty-7 (or master as it was the trunk) and jetty-8. > > We take the jetty-8 branch and rename it to jetty-8-historical and then make a > new jetty-8 branch and commit one mammoth patch taking the diff of jetty-7 git > and jetty-8 svn branch. That should eliminate any hinky merge issues that > might crop up from the jetty7 and jetty8 merging process up to this point. > > I was also thinking that since we are hot on the path of pushing jetty8 then if > we are going to use a branch named 'master' then we ought to make that jetty8 > and start doing development on jetty8, and merging back to jetty7 the work > needed. That will kick the releasing of jetty 8 into high gear. > > thoughts? You could do it the opposite way, depending on how you want your "development" branch and your stable branches to be. Some prefer that master is the stable branch, others use master as the dev. I prefer master as a dev branch, so if jetty-8 is your development branch, then I would put jetty-8 in master, and make a branch from jetty 7. You can then tag a stable jetty7 commit (pick the one for the various releases), and do your maintaince in the jetty 7 branch. When it comes time to release jetty 8, go ahead and do the release process, tag the commit for the release as jetty 8, and do a branch for jetty 8 at that point for maintenance. Just a suggestion.
When we moved the SpringSource dm Server project from svn to git, we preserved the history, which was really useful, so I'd recommend it for Jetty. (Unfortunately, we had to ditch the (GPL) history when we contributed to Eclipse, but that's another story.)
Glyn, Yes, we would be preserving history for jetty8 under the historical branch and ideally making it dead easy from the start of things to merge the 7 and 8 branches. Perhaps we could just pull it all and it would all work perfectly, but since the changes to support servlet 3.0 on jetty8 were largely made to jetty7 and then merged over to jetty8, I don't think we'll lose much in the way of history and the benefit would be reducing the potential for merge uglies brought on by a colorful merge history.. i am not married to the idea, but they way I see it we won't lose much and it reduces (i think) a potential class of issue down the road.
Does it make sense to have a git repository with a single file (jetty-parent)? Why not have everything in one Jetty repository, and then structure the major components underneath that (e.g. eclipse, jetty, wtp etc)? It doesn't look like the sizes are that significant, and would make it easier to check everything out in one repository but still compile a subset when required.
(In reply to comment #19) > Does it make sense to have a git repository with a single file (jetty-parent)? > > Why not have everything in one Jetty repository, and then structure the major > components underneath that (e.g. eclipse, jetty, wtp etc)? It doesn't look like > the sizes are that significant, and would make it easier to check everything > out in one repository but still compile a subset when required. Well if you are doing a CI build, in that case then everything could be potentionally rebuilt, even if nothing changed in a particular repository. i.e. if eclipse code changed, it may cause the other builds for say jetty-core to kick off as well. I personally would move the jetty-parent, to a releng.git repository, along with other items that rarely change.
(In reply to comment #19) > Does it make sense to have a git repository with a single file (jetty-parent)? > > Why not have everything in one Jetty repository, and then structure the major > components underneath that (e.g. eclipse, jetty, wtp etc)? It doesn't look like > the sizes are that significant, and would make it easier to check everything > out in one repository but still compile a subset when required. Actually, yes, it makes sense to split things up based on how you release things. Since you tag the entire repository when you tag in git, it would make sense that you have all of your versions in sync across the entire repository. When it comes to the jetty-parent, toolchain, etc, the release process/rate is at a different pace/interval than the rest, so having those split out into different repositories does makes sense.
eclipse side of the issue has been completed
