2008/12/4 Johannes Sixt <[EMAIL PROTECTED]>: > because if a fix is applied to the oldest live branch, then it will have > to be merged into the later live branches:
I think that the fixes is generally backported, not the way you said. In any case, the merge is not the solution. It has to be cherry-picking (getting one patch and applying to other branch). The work will be almost the same if there are one or more repositories. > But if SVN is read-only you can't apply fixes there, and you *have* to > keep 4.0, 4.1 alive in git, and merge 4.0->4.1->4.2->master occasionally. I have said to stay in read-only svn only the ancient history. Not these branches that has some activity. These branches stay in other git repositories. So, we will have these repositories: kde-3.5.x kde-4.0.x kde-4.1.x kde-4.2.x (soon) kde (trunk) The rest of the history will be in in the read-only repository. When another new stable branch is out, another repository will be create with the history until the point of *fork* and the work continues in the *main* repository. Of course, I'm talking about the stable repositories, those repositories that has release versions. Each developer will have a personal repository that can live in the git.kde.org server and has experimental branches. >> As for 3.5, at this point in time, it can be considered a completely >> different >> codebase, so anything there can't be merged into 4.2. So it would be either a >> patch or a manual change. > > Fair enough. 3.5 *is* a completely different beast. It's I talking about. It's like another project. Why do we want a copy of the whole history in each developer's computer?? It's useless. Raul Fernandes [EMAIL PROTECTED] _______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
