Page Comparison

...

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.

...

Related Links

• A Git Workflow
• Git for those without Version Control background
• GitHub's wonderful help documentation
• TortiseGit

...

• The entire history of uPortal including all maintenance branches would be copied to GitHub, all new development and maintenance would take place via git.
• The uPortal code in subversion at source.jasig.org would be left in place. The entire /uPortal directory would be made read-only and no further updates would be done in SVN. Optionally the /uPortal directory would be deleted allowing for access to specific revisions but reducing confusion for people new to the project looking for the uPortal source code.The documentation and manual content included in the uPortal source code in early versions of uPortal 2 would be filtered out in the migration to reduce the git repository size. There would be a process that mirrored all post-migration commits to the git repository to the uPortal directory in Subversion allowing deployers using SVN specific integrations to continue using those processes.

Test Migration

A test migration of the uPortal source code has been completed and is available: https://github.com/edalquist/uPortal-GitTest If anyone would like access to play with this throw-away repository email Eric Dalquist.

...

1. Developer Familiarity
   • Primary concern with speed for applying critical fixes for a 4.0.1 release
2. svn:externals
   • Used by some deployers as an alternative to a vendor drop import
   • This should be addressed by the read-only SVN mirroring that will be maintained
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?
   • This should be addressed by the read-only SVN mirroring that will be maintained
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 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

...

For the final migration a mapping of Subversion usernames to GitHub usernames is needed to retain as much history as possible.

The above author list was generated by running svn log | grep -E "r0-9+ | .+ |" | awk '{print $3}' | sort | uniq against the temporary SVN repository used in the SVN to Git migrationPlease add your GitHub account information to: https://github.com/Jasig/svn2git-migration/blob/master/mappedAuthors.txt