Per Inge Mathisen schreef: > On 1/7/07, Giel van Schijndel <[EMAIL PROTECTED]> wrote: >> Well the problem with a local tree would be that I would only be able to >> commit anything but incremental changes without breaking things (i.e. >> without breaking the trunk). > Maybe I should not use the word 'tree'. What I mean is another local > copy of the trunk. Thought you meant as much, so my arguments for a branch vs a local working copy apply here. > If it works in your local copy, it will not break the trunk. Whenever > I want to develop something bigger, I make a separate local copy for > that. So I have one copy for small commits, one for the memory patch, > and so on. That way I can integrate other people's changes that are > done while I am developing my stuff merely by doing "svn up" on each > copy. This seems to me the easiest way to work (alone) on bigger > changes. I apply the same technique, but not for the sake of being able to apply larger changes. I instead use it to separate the purposes or targets of my changes (e.g. general code cleaning, memsystem modifications, etc.). > I am not telling you not to create a branch, I am just trying to see > if you really think this is the best way to work on it. As I said, I > doubt branches give you anything but more work unless you are multiple > people working on the same changeset. A branch (in my opinion) servers another purpose, namely that you can change code more heavily (i.e rapidly). Without having to worry about preventing to break things (in fact a redo of the sound system *will*, at least in the first stages, break things). Secondly it keeps the rest of the system in a more consistent state. Which makes it easier to see the differences between revisions and their advantages (or disadvantages). Thus giving a better overview of what your changes result in.
Plus, merging in the differences from the main trunk from time to time really isn't that difficult. It merely is a simple `svn merge wz/[EMAIL PROTECTED] wz/[EMAIL PROTECTED] wz/branch/blabla` and then resolving all conflicts. ;-) Making it sound easy ain't I? Anyway I'm indeed thinking a branch is the (one of the, because I don't believe in perfection as anything else than a goal) best way to work on it. >> C++ provides easier ways of error handling (e.g. exceptions), plus it >> natively provides OOP. I am aware that some level of OOP abstracting is >> provided in the current warzone codebase since the used technique >> however is not native to the language it is harder to maintain. >> Especially RAII is rather difficult to implement using C (whereas C++ >> provides constructors/destructors and operaters new/delete for an easy >> implementation of RAII). >> >> And secondly the only thing becoming more difficult to maintain should >> be building (i.e. as far as I see). Which I think should be made more >> easy by the creation of a C interface and the fact that the this C++ >> implementation is kept local in a library. > My experience from work, where I maintain a large codebase of mixed C > and C++ code, is that such mixing is a maintenance nightmare. I do not > want this unless there is a very good reason for it, and what you are > providing are arguments to convert all of Warzone to C++, which, even > if you buy those arguments, is a totally different discussion. Although those arguments probably are (just as) good for converting all of WZ, that (i.e. converting) isn't my intention. Anyway I'm going to give it a go with C++ at first. I hope that when you stated this: "I do not want this unless there is a very good reason for it" you didn't mean you object me doing this maintenance and implementing? Plus the additional advantage for a branch here is that C++/C mixing can be tested out/experimented with. And if it really doesn't work the safety of a branch is: you can always delete it. -- Giel
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
