Sakai SVN Vendor Branch Outcome
Soo… yesterday I completed my 2.3.1 Sakai vendor branch merge, and it’s now up on a Rutgers test server. It’s been sanity tested, and is ready for further banging. Speaking of banging… it did take quite a few steps to get to this stage…
Note: 2.3.1 is a small merge, I think it was only about 15-20 affected files. Having said that, it took almost 3-days to get this working right, and do the merge using SVN’s tools, both because of my relative inexperience with SVN and the way Rutgers initially setup our repository. Having said that, I do believe that going through this pain will make the next larger merge (2.4? 2.5?) easier, as well as being good experience to ease migrating to Samigo, Melete, and JForum 2.4.
Notes
- I used Glenn’s .subversion/config for things like auto-props and eol conventions. SVN sets a lot of commit preferences on the client side, so I’ll commit this as well, and we should try to sync up on a common configuration
- Keyword substitution had to be turned on in our repository (
svn:keywords) in order to getsvn diffandsvn mergeto work as promised and omit spurious conflicts caused by keyword substitutions — this especially hurts if your files use the$URL$keyword and come off of a SVN tag… - I had to do a clean import of 2.3.0 into our vendor tree in order to get clean diffs when I pulled in 2.3.1, since keywords had to be substituted for both imports
- I had to use the trunk version of
svn_load_dirs.pland patch it — see Bug 2789 — to get the vendor branch to work - /sakai/trunk in our SVN has been updated to point to the new code, through externals mappings, though given my experience with SVN merging we will likely move to a fully realized trunk in the not too distant future.
- /vendor/sakai/current is an exact replica of 2.3.1 minus 5 files that SVN would not import correctly (1 croation js calendar localization and 4 docbook XML files)
- Then I ended up merging changes from 2.3.0 -> 2.3.1 module by module into our local Sakai repository
That was it! 