On Sunday, 7 January 2007 at 14:17, Per Inge Mathisen wrote:
> 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.
>
> 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 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.
I see several advantages to a public branch compared to working just on
a local copy:
- Other people have the chance to comment, test, report bugs, help with
coding... (impossible if noone knows what you're doing).
- Smaller changes. On a local branch you can only make one big patch
that has to work (more or less) before being applied. A SVN branch
records your steps while working, enabling people to follow your work,
and understand the new code easier, as well as giving more
fine-grained changes to look for eventual bugs.
(Of course you can use a local revision control system to work with
and record your patches, and when it all works, apply those
subsequently to SVN. But that's more work, and you lose the "time
factor" that let's people follow your progress.)
I am not saying that this will happen with a public SVN branch, but with
a local branch, it can't even happen.
> >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.
Hm, and the current code isn't a maintenance nightmare? I think using
some C++ to encaspulate stuff will make things better, not worse (if
done right, of course, but you can write bad and good code in both C and
C++). That might be possible with C as well, but to me it seems more
natural in C++.
What I don't agree with is making a C interface to a C++ interface to
OpenAL - seems like duplicated work to me. I'd just use C++ in the code
and compile the complete game with a C++ compiler. But that's just me, I
guess there needs to be some decision about how to use C++, or we just
follow the usual "those who do decide" approach.
--
standards, n.:
The principles we use to reject other people's code.
_______________________________________________
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
