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