Trying to clean up the 1.0 branch...

Hi, Our 1.0 branch is quite a mess... As I said when we voted to create it has 2 drawbacks: " Cons: * Requires more discipline. People must be careful to commit on the right branch/trunk. * We absolutely need to merge to trunk whenever someone commits to the 1.0 branch as otherwise merging is a big pain later on. " I've just done a quick review of commits and I can see the following are not on the 1.0 branch where they should be: 2404 2405 2406 2439 2349 2332 2254 2209 2122 In addition the following are also on trunk but not on the 1.0 branch. However it's possible they're not on the 1.0 branch because we don't want them there but I doubt it. The reason I doubt it is because 1) they're all related to GWT and we've already committed GWT stuff on the 1.0 branch and 2) I'm pretty sure projects using GWT and XWiki will need a released version of XWiki before 1.1 comes out. I may be wrong. Let me know if we really don't want them on the 1.0 branch. They are: 2460 2475 2438 2403 2402 2351 2237 2236 2235 2225 2210 2124 2123 Note: The 1.0 branch was created at revision 2017. Notes: - I haven't done a comprehensive study (way too long). I only did with a search with some heuristics. - I haven't checked for commits on the 1.0 branch but not merged back to the trunk As a consequence, it's very likely there are commits other than the one listed above that may be lost. Last, I did today a merge of the skin rename from 1.0 branch to trunk (in rev 2479) and I've noticed that changes on trunk which were done on skin files but that had not been merged to the 1.0 branch have been lost. I find this is very dangerous and I don't understand why SVN did not warn about this and fail the merge. IMO it should have. I think this only affects commits done in skin files in revs 2404, 2405, 2406 and 2439 (fixes for the Exo integration) but I can't be sure. I'll manually recommit those. If you see anything amiss please let me know. Last, I've discovered a nice tool call svnmerge.py (http:// www.orcaware.com/svn/wiki/Svnmerge.py and http://kenkinder.com/ svnmerge/) which makes it easy not to loose stuff and easily merge all changes from one branch to another. Only issues are: - it seems to work only after you start initializing it. I've done that on the xwiki/xwiki/trunk directory, telling it to track changed with the 1.0 branch - I tried to iniitialize it on the 1.0 branch to tell it to track changes from the trunk but it fails mysteriously. If someone knows why or how to fix it, I'll be glad to hear - I tried runnning it on xwiki/xwiki/trunk to merge 1.0 branch changes and I got lots of skipped files and lots of conflicts. As I don't full understand what it does I didn't pursue it. I still feel it's a good tool. If it works as expected I think we wouldn't have to have everyone do manual merges and the branch manager could run it from time to time (at least before each release). I would be happy to do that. However as I haven't been able to make it work yet, we shouldn't do that right now. So the question now is: What do we do? I'll try to clean up the above (For the record it took me the whole afternoon and more to do the detective work and it'll take me another half day to do all the merges) but what do we do after? Do we continue with a 1.0 branch? Do we remove it and work on trunk for the 1.0 release? My feeling is that we should try using this svnmerge.py script and get it working. However I'll have to spend some time to get to that state. WDYT? In the meantime it would be good if everyone could check his own commits since rev2017 and verify that everything has been correctly merged in both directions. Thanks -Vincent