Hi, i'm taking this bugreport for starting a general trunk <-> freewrt_1_0 situation discussion. Fixing this single bug does not correct the overal problem.
From my point of view, trunk is in a more or less desolate state, because there are changeset in 1.0 that didn't make it to trunk. Somebody will have quite a hard time finding and merging all of them. If only one single functional or bugfixing change gets lost in trunk, there will be regressions in the 1.1 release, which will be branched from trunk again in a few months. svn is _not_ capable of tracking merges between branches. Because the changes that actually went to both branches are also _not_ wisely commented (most of the time "Sync with 1.0 branch"), it's not easy to get an overview of already merged changes, unmerged changes and changes that don't have to be merged (i tried...). Theese factors prevent a somewhat half-automatic solution imho. For the future, i would like people starting to put ALL changes (minus the ones that clearly and intentionally only belong to stable) to trunk first, and merge them to the stable branch afterwards. While the other way round is equal on the functional side, i think it's psychologically better to do it this way. And it prevents regressions in future versions, because even if some change is not merged by accident, it will hit at least the next stable branch. Additionally, i hope that the commit messages for merges will be more meaningfull in the future. For whole changeset merges, i think of something like: "Merge whole changeset [1234] from trunk: Added Feature A Added Feature B Added Feature C" And for selective merges (you committed features A,B,C to trunk with a single changeset, but only want B in stable): "Selective merge from changeset [1234] from trunk: Added Feature B " Or we just switch to some more advanced source code management system that is able to track merges for itself, but i'm not eager to reiterate this discussion now. Personally, i choose to merge the changes in trunk i need/want (for example ccache) from trunk to 1.0, because this gives me the best of both worlds. But there is really a need for a general solution, if possible by any chance even before the stable release. I hope somebody smarter than me will take care of the problem and deploys a good solution. Enough nagging for today, good night =) -- Lothar Gesslein <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ freewrt-users mailing list freewrt-users@freewrt.org https://www.freewrt.org/lists/listinfo/freewrt-users