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 boldA 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. 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 *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:3. 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?*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.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.4. 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*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/29d561b06ae96966I'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+ProposalI 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.htmlThere 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.htmlGitHub'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 <http://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 uportal-dev@lists.ja-sig.org as: eric.dalqu...@doit.wisc.edu To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
smime.p7s
Description: S/MIME Cryptographic Signature
