I was originally a 0 on this issue; I think the primary committers by and large won't have too much difficulty switching to git, but I shared some of the earlier concerns about deployers depending on svn.
Now that this read-only mirror is possible, my vote is +1 as long as that becomes a required step in the transition. I also think we should capture in video form a number of common workflows for deploying and contributing patches using git to help those that are interested make the switch. On Wed, Sep 14, 2011 at 8:49 AM, Eric Dalquist <[email protected]>wrote: > I've verified that we will be able to the keep the existing > https://source.jasig.org/uPortal svn data as a read-only mirror of the git > repository. Existing revision numbers will not change and commits on the git > side to the trunk and patches branches will automatically be reflected back > to the Jasig svn repository. Hopefully this will address the needs of folks > that are using svn:externals and the svn remote-merge features. > > -Eric > > > On 9/11/11 9:48 PM, Eric Dalquist wrote: > > I'll be interested to hear what you hear about the Jasig/Sakai stuff. The > talks we've had on the steering committee assumes that there will be work to > merge infrastructure but that project governance will remain with the > project steering committees, for example CAS3, mod_auth_cas, and > phpCAS-Client have all moved or are in the process of moving to GitHub. > > I'll look more into maintaining a read-only SVN clone of uPortal, > potentially in its existing location (this is complicated by the complicated > nature of the uPortal history). I'm guessing we could have a bamboo job that > would run git-svn post git commit to keep things in sync. > > -Eric > > On 9/11/11 6:00 PM, Steve Swinsburg wrote: > > Hi Eric, > > A could of responses inline: > > > On 12/09/2011, at 1:01 AM, Eric Dalquist wrote: > > Since the concerns need some actual discussion I'll see if I can answer > them here, my answers are in bold > > 1. Developer Familiarity & Conversion Lag > - Primary concern with speed for applying critical fixes for a 4.0.1 > release > - *I have done a test release using the maven release plugin against > github and the developer workflow does not change for cutting releases > * > - *There are ~ 6 very active committers on the project, I'll be sure > to touch base with each of them and get their vote before we make any > move > * > 2. svn:externals > - Used by some deployers as an alternative to a vendor drop import > - *I'd like to get more insight on this approach versus doing a > vendor drop* > - *One option is for Jasig to maintain a read-only SVN clone of the > git repository if there is enough interest from those using > svn:externals > * > > A subversion clone of the git repo would be handy, at least initially. It > would actually tie in with 3 below, assuming the history is kept intact. > > > 1. Local deployments using Subversion (if Subversion is their > institutional repository) > - Process to merge fixes into local repository directly from the > uPortal repository? > - *Are there examples of a patch merging process that is specific to > uPortal using Subversion?* > > Not specific to uPortal, but specific to Subversion. For example, we use > the vendor drop method for major releases, however from time to time we want > to pull in a patch that has been added to the branch. So we can simply grab > that fix from the uPortal repository via an svn merge: > > svn merge --dry-run -c12345 > https://source.jasig.org/uPortal/branches/rel-3-2-patches/ > > We could generate a patch, but it saves a bit of extra work. Having the > subversion repo clone as in 2 above would allow this practice to continue. > At some stage we may be able to move to a git repo, but not soon. > > > 1. Sakai-Jasig merger > - How will this relate to the merger and any broader SCM/Release > management strategy? ( > http://groups.google.com/group/jasig-sakai-collaboration) > - *As far as I know projects under a merged Jasig/Sakai > Collaboration will still be responsible for setting their own SCM and > release management strategies just as it is now under Jasig* > > I'll be speaking with Ian Dolphin and Josh Baron this week, as they are > in Australia for AuSakai 11. I'll try and get some clarity around this > issue. > > From what I read in the Jasig-Sakai Common Foundation Value Proposition > Document [1]: > "Opportunities exist for bringing new and consolidated resources to bear on > issues such as Quality Assurance..." - I'm presuming that will have some > impact on release management. > > Further, "Consolidating our Technology Infrastructure - We expect to see > cost savings from moving towards a common suite of centrally hosted > communication and coordination tools (e.g. issue tracking, wiki etc.)." - > It's unclear as whether or not that includes SCM. I'll try and find out this > week. > > cheers, > Steve > > > [1] > http://groups.google.com/group/jasig-sakai-collaboration/browse_thread/thread/29d561b06ae96966 > > > > I'll continue to copy over content into the migration proposal wiki page. > > -Eric > > On 9/10/11 8:55 PM, Eric Dalquist wrote: > > I've moved the proposal into the wiki: > https://wiki.jasig.org/display/UPC/Git+Migration+Proposal > > I tried to capture all of the concerns that have been raised in this thread > though they could use more flushing out, especially the svn:externals issue. > > The wiki page also links to a test migration of the uPortal project to > GitHub that I did this weekend: > https://github.com/edalquist/uPortal-GitTest Please take a look around and > let me know if you'd like commit access. > > Lastly one thing that the move to GitHub fixes is Fisheye. We were able to > turn fisheye back on pointing to the Jasig SVN repository by having it > ignore the entire uPortal source history. That's great for other projects > but for uPortal it was a problem. We were also able to get Fisheye working > against the uPortal-GitTest project: > https://developer.jasig.org/source/browse/~br=master/uPortal-GitTest > > -Eric > > On 8/31/11 2:26 PM, Eric Dalquist wrote: > > I'd like to see uPortal's source code moved to git and hosted on GitHub. > There have been quite a few folks that have been working on uPortal 4, > uMobile or are otherwise interested that have asked about using git. After > looking into it a bit more I think it would be a very valuable change for > uPortal. > > For those not familiar Git is a *distributed* source control tool. What > that means is there is no true central repository like there is with SVN. > Developers don't really checkout some version of the code, they clone the > entire project when doing work. That doesn't prevent the convention of a > central repository which is what a site like GitHub provides. A place to > host a clone of the project that by convention we agree is the master copy > of the project. > > GitHub adds some very nice social-coding aspects to git. Primarily it > provides a VERY easy interface that allows anyone to clone a project, make > changes and commit them to their clone, then make a pull request on the > master project. Once that has happened a simple click of a button is all it > takes for any developer with commit access on the master to accept the > changes and merge them in. This process makes it very easy for people > without direct commit access to commit changes that are reviewed by a core > developer before merging in and significantly simplifies the work of the > core developers. > > When there was first talk among about switching I solicited feedback from > the Fluid project which recently moved from SVN to Git. I highly recommend > reading the resulting thread which highlights a lot of the pros and cons > http://old.nabble.com/Perspectives-on-Git-td31852449.html > > There is an eclipse Git Plugin, a TortiseGit client which is a clone of > TortiseSVN and I believe most other IDEs have either built in or plugin > support for git. > > Some other useful links: > Git for those without Version Control background - > http://hoth.entp.com/output/git_for_designers.html > GitHub's wonderful help documentation - http://help.github.com/ > TortiseGit - http://code.google.com/p/tortoisegit/ > > Some questions that I can try and answer before they come up: > - The uPortal code in svn at source.jasig.org would likely be left in > place, we would just make the entire /uPortal directory read-only > - We're going to filter out the documentation and website files that were > included in early versions of uPortal 2 to reduce the project repository > size. > > Since this is a big change (and since I'm going on vacation for 2 weeks > starting Friday) I'm planning on leaving this vote open for a while. +1, 0, > -1 to vote and if you vote -1 you need to include a detailed reasoning for > your -1 vote. > > -Eric > > > -- > > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-dev > > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
