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]>

Attachment: 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

Reply via email to