Actually make that:
astyle -j -s4 -o -a -p -a --convert-tabs
the -a forces curly brackets to attach to the previous line.
Ian
I'd just like to ask anyone submitting patches to run the following
astyle command on the sources before posting them:
astyle -j -s4 -o -a -p --convert-tabs
this will
Hi Ian,
I got around to writing it but it has some bugs that still need to be
worked out. The current state is:
1) Only runs against nant build on date: 2003/09/23
- not sure why but the task seems to hang on builds
after
2) Bug in namespace/ class indentation:
I'd just like to ask anyone submitting patches to run the following
astyle command on the sources before posting them:
astyle -j -s4 -o -a -p --convert-tabs
this will enforce most of the nant coding guidelines with regard to formatting and layout and makes the reviewer/committers job much easier
Hi All:
I am a cvs expert and would like to referr you to the following
branching patterns assembled by Brad, et al:
http://www.cmcrossroads.com/bradapp/acme/branching/
Using these patterns, I have effectively managed projects
in the past. The ones I recommend for CVS are:
Branching Policy:
I've been thinking about some of the target dependency functionality,
and I was wondering what people thought about having some extra
specification of target ordering. There's a couple of types in here, so
I've broken them up. I'm interested in hearing opinions of what people
think of these.
This test was leaving behind a tmp file. it now cleans up after itself.
I didn't compress the patch cause the compressed file was bigger than the
patch!
Michael.
console-nanttest.patch
Description: Binary data
Thanks Stefan,
that kinda gels with my feeling on it. Maintaining a branch for a long
beta cycle can be painful but maintaining development thru a long beta
without branches can be even more so. If there are a bunch of patches
coming thru to go against HEAD - ie new features that wouldn't make t
Not quite so easy. There is some code that uses P/Invoke and will fail -
or at least give ugly warnings when run on mono. Ideally we should
probably re-code these areas so that everything thats not in the Win32
namespace runs fine on mono when built on ms .net.
Ian
Can't you just use the binari
From my reading of the docs they are not orthogonal. ie when you are
satisfied that the source is in a releasable state then you add the
rtags so you can always get that version at a later date. Branching
however gives you a seperate dev line which enables you to polish a
release while still ma
On Fri, 21 Nov 2003, Ian MacLean <[EMAIL PROTECTED]> wrote:
> Maybe I'm missing somthing but I'm not convinced by the 'branches
> are bad' argument. Is there some published documentation that says
> that this is so ?
Let's say that branches are great if you know enough about CVS are and
can deal
Maybe I'm missing somthing but I'm not convinced by the 'branches are
bad' argument. Is there some published documentation that says that this
is so ? I was under the impression that creating a release branch and
merging any bug fixes back in was the 'standard' way of doing things
with cvs. Wha
11 matches
Mail list logo
