On Mon, 2002-11-04 at 09:35, Victor Mote wrote: > I'll take your word for how it is used in real life, and this perhaps > explains how we got to the status quo. I just wonder "why?" It seems like > tagging only the subset of files that need to be different is a much more > elegant way to handle the problem. It 1) greatly simplifies the commit > process (it really eliminates the "educating committers" problem that > Jeremias mentioned), 2) defers branching individual files until they must be > branched, 3) provides a moderately easy way of knowing which files are > actually different. It requires only that when a file needs to be added to > the branch that someone run a "cvs tag" command on that file, and that if > you are working on the branch you use "cvs checkout -f" to make sure you get > the trunk version of the common files. If you fail to do the latter, the > compiler will no doubt remind you.
The selection of the branch really was simple: - the old code had a number of problems - we were getting nowhere trying to improve on that code due to the poor design creep - the code was branched only for bug fix updates with the intention of abandoning it - branch for old code simply as reference and for bug fixing - new code on trunk as the main development focus - work on new code to address design problems Redesign, rewrite call it what you want. The design of some fundamental parts is different (area tree, renderers, xml handling, image handling, layout), a number of things where rewritten to accomodate the different design approach. I really don't think that you can say, even with the benefit of hindsight, that working from the original code would have got us towards a better design in the same time. Quite simply the code was a mess. > BTW, it is this viewpoint that makes me think that we have the branches > reversed. If the working / maintenance code is the core code that you start > with, then the new design code is the stuff that is branching off. Go back > to the point in time immediately before the first file was changed in the > redesign work. You modify file foo.java and want to commit it to the > repository as the first piece of the redesign. You have decided that the > redesign will live in the trunk and that the old code will be pushed onto a > branch (exactly as we have done). The only way that you can accomplish this > is to force a checkin of the code that **did not** change onto the branch. > Other have pointed out that it really doesn't matter where the branches are, > and in a strict sense they are correct (and we can use the admin -b to > change the default branch if we want to). However, it seems extremely > awkward and counter-intuitive to create a branch on code that didn't change. > I don't feel strongly about the position of the two branches. However, there > seems to be general agreement that this is a complex project. Since > complexities tend to be exponential in nature, every one of them that can be > eliminated tends to have a large benefit. As I have said a number of times and will continue to say. The old code was linked all over the place making it unecessarily complex, a suitable design was not forming and there was essentially no hope of implementing certain important features. We needed to start from scratch in some areas and attack it from a different perspective. There didn't seem to be a need to waste a lot of time bringing across the old code in gradual steps. Even now it seems like it would take far longer to bring across in small steps than it would to simply focus on what we have now. Should we then focus on a simpler cleaner design to get rid of these exponential complexities. How good does it need to be working before you will consider it suitable to work on. Keiron --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
