Keiron Liddle wrote: > Actually projects like mozilla have branches for maintanence but the key > is that they are short lived, this didn't work out like that.
I don't know this, but I'll bet that the maintenance branch that you refer to here is for bug fixes, while the main development line progresses *incrementally* on the trunk. The reason why ours didn't work out that way (I suspect) is because we tried to do a chasm-type change on the trunk, where we had to break the code to go forward. With 20/20 hindsight, it is easy to see that the chasm change would have been more convenient to manage on a branch. In this respect, it is no different from a normal patch. For a normal patch, your sandbox is a kind of branch. Only after the code is completed and tested do you commit it. The only difference with a chasm-type change is that, because it is so big, you want to be able to put incremental changes into source code control so that can keep a history. The principle still remains that only after it is completed and tested should it be merged (committed, if you will) to the trunk. As you correctly point out elsewhere, this is all water under the bridge. I mention it only because I suspect that it explains the difference with mozilla. > I think you have misunderstood something. There has been a great number > of changes across many packages and classes in trunk. The reason being > that the code was (and still is in the branch) in a bad way, this > occured gradually more because it wasn't prevented from hapenning. > For example the link support, pdf library, image handling. > It becomes quite obvious when you understand why there are so many bugs > with link positioning, image handling and further causes of memory > leaks, excess memory usage. I think I understand. However, the question is not the quantity or even location of the changes that have been made, but the scope. The real question is how many of the changes that have taken place in the trunk are changes that were applicable only to the trunk -- in other words, are a lot of them changes that would have helped or at least not hurt the maintenance branch? > This is what seems to be the real problem. You think that the branch is > mostly okay and only some of it has changed in the trunk. This isn't > really the case. I didn't mean to imply that the branch is mostly OK, but I understand your point. > The code in the trunk is more advanced in a number of ways. Such as > transparency, link handling, image handling, gstate, graphic state. > Now if you are to improve the code in the branch it will mean either it > has already been done or that the changes will need to be brought across > from old code to new changed code. In some cases the changes will > compound old problems (for example you used the MessageHandler). > Now if the improvements are made in trunk this is more likely to be > handled better, the code could then go across to improve the branch. This seems to support my point that some of the files were unnecessarily forked, but I sure might be missing something again. Also, it is possible that, even if the unnecessary forks could have been prevented in the past, the fact that they took place has led to unfixable differences. For example, if one branch was refactored for X, and the other was not, it will be more difficult to merge them now. I suspect that your MessageHandler citation is such an example, as I was imitating other maintenance branch code. > There isn't really that much on the branch that is relevant to the > trunk. The thing the branch has is that the layout works (sort of) and > it is a complex beast to do properly. > > > Maybe the simplest is to move the old layout to the trunk, get that > working and put the new layout in a branch. But it needs to be agreed > upon. The key here is to divide the differences between the two branches into two groups: 1) those that *must* be different between the branches or that cannot be efficiently reconciled, 2) those that can (efficiently) be merged without breaking either branch. If the differences are heavily in the first class, we should just continue on from where we are. If they fall substantially in the second class, then the plan you propose above makes a lot of sense. While we are in a brainstorming mode, please forgive me for throwing out another wild hare to consider. (This only makes sense if most of the differences are in the second class): Is it at all feasible to maintain both layout managers in one set of code? In other words, for the choice to be selectable or pluggable? Perhaps put the old logic into an oldlayout package. If there is a lot of potential commonality between the code, this would give us an opportunity to reunify the two branches right now, and simply blow the old stuff away at some point in the future when it is no longer needed. It would be worth *a lot* to get the branches unified if at all possible. If it is not feasible to unify significant portions of the two branches, either by switching them in the repository or by putting them into one branch, then I propose that we clarify our terminology by using the term "rewrite" instead of "redesign". This would signal that we are not merely rebuilding an important module, but that the changes are pervasive, and that the old code has been effectively abandoned. Keiron, I'm sorry to keep asking you to answer the same question over and over again. I guess I've never had to totally abandon useful code before (however moderate the usefulness might be). If, after considering the above points, you are sure that we are on the right track, I'll do what I can to be useful on the trunk. Unless you have a better idea, I'll continue with the font work -- just understand that the refactoring work will be much more likely to introduce bugs when I am flying blind than it would be with working code. Thanks for your patience. Victor Mote --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
