On 10/29/2006 01:56 PM, Graham Leggett wrote: > Ruediger Pluem wrote: > >> Apart from this, Paul created a branch a while ago for mod_cache >> refactoring. >> As it has turned out the whole thing creates some bigger discussion >> and patches >> go in and out. So I think it would be a good idea to do this on a dev >> branch instead >> of the trunk. So I propose the following thing: >> >> 1. Create a dev branch again for mod_cache based on the current trunk. >> 2. Rollback the patches on trunk >> 3. Work out the whole thing on the dev branch until there is consensus >> about >> the solution and only minor issues need to be addressed. >> 4. Merge the dev branch back into trunk. >> 5. Address the minor issues on trunk and tweak it there. >> >> This gives people who cannot follow up the whole history the chance to >> review >> the whole thing on step 4. as some sort of reviewing a complete new >> module :-) > > > A trunk by any other name, will still smell as sweet. > > If the branch was created beforehand, then this would have made sense,
It was there, but sadly it was not used. But I admit that I should have pointed out this much much earlier, so this is also my fault. > but to have created the branch so late in the process, we are just > creating work for ourselves that will ultimately end up with the same > result. > > Currently history reflects the reality of what was tried along the road, > what was objected to, backed out, and tried again. > > If we redo this without the objected-to bits, we are simply rewriting > history (literally), thus removing the history's real value. We actually do not remove the history. It will still live in the branch, but yes on the trunk once we merge the branch back in it would look like some kind of magical jump. To get all the gory details you need to go through the logs of the (then deleted) branch to get all the history of the back and forth and the rationales. Regards Rüdiger
