Whatever the case, if someone wants to put their hand up to maintain
the git repo, I've already got stuff I want to fork :)
Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla 1.6 developers
> --
> You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
> To post to this group, send an email to joomla-...@googlegroups.com.
> To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>
>
Maintaining both simultaneously would be tricky though. I think this is the kind of thing where you have to say "we're doing it on date x" and then just do it. No matter when you end the Subversion support, you're always going to have someone out there who isn't ready yet.
I think a lot of people have moved to using Git for their personal projects already, but there are still people who haven't yet gotten practice with it. So I'd like to do a survey to essentially answer this question: if we moved to Git tomorrow, how many people would have trouble contributing?
-Joe
My two cents: use the time between the 1.7 and "next version" release to
transition to Git and once "next version" is released, the SVN is done.
From right now, that's about 7 months for devs to get comfortable with the
differences, new info to be added to the docs site, and complete the
transition.
I am new to Joomla but I've been looking into sorce control for a while now and still don't fully understand the concept although i understand the reason for it in terms of Joomla.
I find that git seems better documented but more complicated and subversion is quite easy but the documentation lacking. For a new developer how do they come to understand the concept?
However, now that you mention it, we might be able to get away with leaving SVN as a "read only" repository. In this scenario, the only commits going back to SVN would be ones merged in over at GitHub. That way, if testers are used to reading from the SVN repo, they can still access that for a while, but all of the patches get written over at GitHub.
And yes, I think that schedule (start with Git after 1.7, phase out SVN after "1.8") sounds reasonable.
-Joe
I like Joe's suggestion about a first stage being to make SVN read
only - I think that's something to consider. But Elin's also right in
that shifting the code repo is just one aspect of a larger workflow
that needs to be considered. Issue management also has to be part of
the strategy.
Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla 1.6 developers
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/joomla-dev-cms/-/vCrPc-oz8vEJ.
--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
Ok, the survey is up: https://spreadsheets.google.com/spreadsheet/viewform?formkey=dHRkWE1vZ1lMbHVOVFlzZkQ3VkdtMXc6MQ&ifq-Joe
I don't think there's a point in creating a Git mirror of the repo if nobody is allowed to commit to it. How would anyone be able to effectively use it?
As far as the patch formats go, yes this is true. However, SVN users could still do a full checkout of your Git fork that includes the patch. Now yes, it would take longer to do the checkout than to apply the patch. However, I think we're ultimately looking at a situation where people are going to be pulling code from fork branches rather than applying patches from text files posted to trackers. For instance, I was able to apply some of your Joomla Platform patches just now by doing this:git pull git://github.com/realityking/joomla-platform.git secruitySo instead of posting a patch to a tracker issue, you would post a URL to a branch where the commits can be pulled.The SVN equivalent would be to check out your repo like this:
Unfortunately, it can only check out your master branch, so your patch would have to go into there.
Final call for anyone who hasn't yet participated: I'm going to give it another 24 hours, then tally up and publish the results. If you haven't yet participated, it will only take a minute: https://spreadsheets.google.com/spreadsheet/viewform?formkey=dHRkWE1vZ1lMbHVOVFlzZkQ3VkdtMXc6MQ
-Joe
On 23.06.2011, at 17:22, Joseph LeBlanc wrote:I don't think there's a point in creating a Git mirror of the repo if nobody is allowed to commit to it. How would anyone be able to effectively use it?I'd certainly use it. It's a great way to work on some larger features. If the git repro stays in sync with trunk I could just run a diff between the two and submit that as a patch against trunk. (in theory). Also it's a step that would need to be done anyways, so why not doing it sooner rather than later. It would get people a chance to toy around with git.
As far as the patch formats go, yes this is true. However, SVN users could still do a full checkout of your Git fork that includes the patch. Now yes, it would take longer to do the checkout than to apply the patch. However, I think we're ultimately looking at a situation where people are going to be pulling code from fork branches rather than applying patches from text files posted to trackers. For instance, I was able to apply some of your Joomla Platform patches just now by doing this:git pull git://github.com/realityking/joomla-platform.git secruitySo instead of posting a patch to a tracker issue, you would post a URL to a branch where the commits can be pulled.The SVN equivalent would be to check out your repo like this:In a previous discussion we had in the JBS Skype channel some people (including me) thought it would be less disruptive to the bug squad process if we keep doing patches for the beginning. Git has a lot more complexity and we have quite a few members who are completely new to SCM or don't use it for anything outside Joomla
I've compiled the results of the Git survey. I'd like to discuss some specifics a little later, but have a pool party to run off to ;) The majority of the people who participated are actively using Git and supportive of the move. Most of the concerns are about the Bug Squad workflow.
After keeping the survey open for almost a week, 86 people responded. The complete results can be viewed here: https://spreadsheets.google.com/spreadsheet/ccc?key=0AsADis6j-2VldHRkWE1vZ1lMbHVOVFlzZkQ3VkdtMXc#gid=0
Bear in mind that this is by no means a scientific survey (nor was it intended to be one). This is to say: everyone who participated in the survey did so voluntarily, rather than be selected by random sampling. The intent was to get a rough picture of the awareness and comfort level with Git in the Joomla.
Almost half (41) of the responses came from people who write patches. The same number of people are also members of the Joomla Bug Squad (although not necessarily the same 41). Slightly over a third (30) only report issues on the tracker and do not test patches.
While the majority actively use Git in at least one project (53), there's still a significant number of people who've either tried it a couple of times, or not at all. The vast majority (69) have been to GitHub.com, and 57 have downloaded or otherwise worked with code there.
Nearly half (41) would be immediately functional if Joomla switched to Git today, with the majority (59) at least being able to figure it out quickly. A small portion (4) would find a switch difficult.
Almost every response was from either a programmer or someone who does a little bit of everything.
The comments revealed a lot of enthusiasm over moving to Git as soon as possible, along with some concerns and questions over what the new workflow would entail. Comments in favor of a speedy move cited the following points:
* Ease of contributions under Git
* The need to have the Joomla Platform and CMS maintained consistently
* Ease of branching
* Would encourage more participation from Git users
* Joomlacode.org is dated
* Windows clients are now plentiful
There were also some concerns about the move:
* Desire to keep using Joomlacode for 3PD extensions
* The need for updated tutorials
* Whether or not GitHub has sufficient issue tracking/sorting for a project of Joomla's size
* The ability to follow repository histories after merges
* Numerous GitHub "forks" might make merges more complicated
* The need to rewrite SVN maintenance code
Several responses came from people who were unfamiliar with Git, or were unsure of what a move to Git would entail.