New subject: [xwiki-dev] Trying to clean up the 1.0 branch...

23 Mar 2007

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