Re: [nant-dev] patch submissions and coding style

[Ian MacLean]

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 enforce most of the nant coding guidelines with regard to 
formatting and layout and makes the reviewer/committers job much easier.

you can get astyle from http://astyle.sourceforge.net/. btw there was 
talk of writing an astyle task a while back. Did anyone get around to 
doing that ?

Ian





---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers


--
Ian MacLean, Developer, 
ActiveState, a division of Sophos
http://www.ActiveState.com



---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers

RE: [nant-dev] patch submissions and coding style

[Clayton Harbour]

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:
- seems to NOT indent classes, making namespace and
class line up on the same line.
3) Unit tests
- none

There is some documentation for how to set the tool up.  If anyone has
the time to spare to look at what might be going on I can forward a zip
to the list.  Alternatively the tools directory in sharpcvslib.sf.net
has the nant-task and the nant binary from 2003/09/23 if you feel
comfortable with checking it out from there.



Clayton

> -Original Message-
> From: Ian MacLean [mailto:[EMAIL PROTECTED]
> Sent: November 21, 2003 8:26 PM
> To: [EMAIL PROTECTED]
> Subject: [nant-dev] patch submissions and coding style
> 
> 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.
> 
> you can get astyle from http://astyle.sourceforge.net/. btw there was
talk
> of writing an astyle task a while back. Did anyone get around to doing
> that ?
> 
> Ian
> 
> 
> 
> 
> 
> ---
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> ___
> nant-developers mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/nant-developers


---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers

[nant-dev] patch submissions and coding style

[Ian MacLean]

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.

you can get astyle from http://astyle.sourceforge.net/. btw there was talk of writing an astyle task a while back. Did anyone get around to doing that ?

Ian





---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers

RE: [nant-dev] NAnt Tag and Branch policies

[Jordan, Tom]

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:
Deferred Branching
Codeline Conventions
http://www.cmcrossroads.com/bradapp/acme/branching/branch-policy.html#Deferr
edBranching
http://www.cmcrossroads.com/bradapp/acme/branching/branch-policy.html#Codeli
neConventions

Branch Creation:
Codeline per Major Release
http://www.cmcrossroads.com/bradapp/acme/branching/branch-creation.html#Code
linePerMajorRelease

Branch Structure:
LAG Development Line
Parallel Releasing/Development Lines
http://www.cmcrossroads.com/bradapp/acme/branching/branch-structs.html#LagLi
ne
http://www.cmcrossroads.com/bradapp/acme/branching/branch-structs.html#Paral
lelRelEngDev

With this said, what we do is this:

Mainlineproj-1-0-branch

proj-1-0-build-1
proj-1-0-build-2
proj-1-0-build-3 == proj-1-0-base <== release candidate (pob)
proj-1-0-build-4
proj-1-0-build-5  <== formal release (document)
proj-1-1-build-1^- map: cvs-tag:
proj-1-0-build-5
proj-1-1-build-2rel-tag: proj-1-0
...etc...

rtag'n and tag'n are basically the same; they just create a tag
in the repository.  However, you really should use plain old "tag"
when you identify the stable builds.  Reason: you just validated
that the source in your workspace builds correctly; if you try
to do an rtag instead, you risk someone checking into the HEAD
and you will be tagging an unverified build-set.

rtag'n should be reserved to those times when you want
to create a branch off an _existing_ tag.  There is
no reason to rtag the HEAD unless you have a very
small development group.

hth,
-- Tom.

PS> Please note that Activity Branches and Branch per Task just cause
massive headaches with CVS
http://www.cmcrossroads.com/bradapp/acme/branching/line-elems.html#ActivityB
ranch
http://www.cmcrossroads.com/bradapp/acme/branching/branch-creation.html#Bran
chPerTask



> -Original Message-
> From: Ian MacLean [mailto:[EMAIL PROTECTED] 
> Sent: Friday, November 21, 2003 1:10 AM
> To: Scott Hernandez
> Cc: [EMAIL PROTECTED]
> Subject: Re: [nant-dev] NAnt Tag and Branch policies
> 
> 
>  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 making changes to the main branch. If you 
> choose not 
> to branch and the release process takes any length of time 
> then all the 
> commits waiting to go onto the main line have to be queued up. If a 
> branch is made the sources should still be rtagged on that 
> branch prior 
> to release - its not really an either/or situation.
> 
> see: http://www.kagekaze.org/cvs/cvs-talk/releng/tags.html
> 
> Ian
> 
> >
> >I'm not a cvs expert, but it seems like we are not doing 
> this correctly 
> >if we create a branch before we make a release. We should be 
> rtag'n and 
> >not branch'n.
> >
> >- Original Message -
> >From: "Clayton Harbour" <[EMAIL PROTECTED]>
> >To: "Scott Hernandez" <[EMAIL PROTECTED]>;
> ><[EMAIL PROTECTED]>
> >Sent: Wednesday, November 12, 2003 7:43 PM
> >Subject: RE: [nant-dev] NAnt Tag and Branch policies
> >
> >
> >  
> >
> 
> 
> 
> 
> ---
> This SF.net email is sponsored by: SF.net Giveback Program. 
> Does SourceForge.net help you be more productive?  Does it 
> help you create better code?  SHARE THE LOVE, and help us 
> help YOU!  Click Here: http://sourceforge.net/donate/ 
> ___
> nant-developers mailing list [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/nant-developers
> 


---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers

[nant-dev]

[Matthew Mastracci]

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.

1.  Explicit ordering of user-passed targets

One of the patterns seen in the NAnt buildfile is the "property target". 
 Examples of this include the framework selection, release/debug 
selection, etc.  It would be nice to specify the explicit ordering of 
these targets, without introducing a dependency.  For instance, 
something like this could be possible:



This would tell the dependency engine that the debug/release targets 
must run before any of build/test/deploy.

2.  Allowing targets to provide a virtual dependency

This would allow one or more targets to provide a "virtual" target that 
could be used as a dependency in later targets.  For instance:





Any comments/suggestions/flames?  :)

Matt.

---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers

[nant-dev] small patch to NAnt.console/NAntTest.cs

[Michael Aird]

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

Re: [nant-dev] NAnt Tag and Branch policies

[Ian MacLean]

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 the 
release, it becomes very difficult to manage them all while the current 
release is finalised and there is a big risk of those changes being lost.

Ian

Stefan Bodewig wrote:

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 with them.  If you don't, well, they aren't that bad.  Just
make sure they don't live for too long.
The major problem is merging changes from one branch to another.  If a
branch is only short lived, this is no big deal.
 

Stefan do you know what the Ant/Apache policy on this is ?
   

There is no Apache policy.  Different projects are doing very
different things.
The process for Ant is essentially to create a branch with the first
beta.  Development for the release happen on the branch, new
development goes on on the main branch.  It works, but the longer the
beta period the more pain is involved.
For more details on Ant's process, see
.
Stefan

---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
 



--
Ian MacLean, Developer, 
ActiveState, a division of Sophos
http://www.ActiveState.com



---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers

Re: [nant-dev] Criteria for next release

[Ian MacLean]

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 binaries from .NET 1.0 on Mono, too ?
You could just ignore some tasks, and it should be fine...
Jarek

- Original Message - 
From: "Scott Hernandez" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, November 07, 2003 6:21 AM
Subject: RE: [nant-dev] Criteria for next release

 

That is a negative Jason. We will always distribute source with our
   

binaries. We will
 

also always include help/documentation.

We will also not distribute multiple, and redundant, binaries. There is no
   

reason to
 

distribute 1.0 and 1.1 compiled versions of nant.

Our goal is to support all .net platforms and frameworks. Right now NAnt
   

has support for
 

the ms .net framework 1.0 and 1.1, as well as limited support for mono (as
   

mono
 

progresses our available features are also growing). Our goal is to
   

provide binaries
 

that meet the minimum framework requirements. In the future I expect our
   

compiled
 

binaries will run on mono out of the dist directly, just like they do on
   

the ms .net
 

frameworks.


   

John,

Thanks for taking up this task...any further progress on releasing the
first beta or release candidate?
My vote would be for one distribution package with the binaries for each
.NET framework  in separate directories.  I don't think that we should
include the documentation or source in the distribution package.  We
should instead, direct users to the website for documentation.  I would
include a readme doc that explains the basics of getting things setup
(for the newbie), but again, refer to a task reference on the web.
From my perspective, if I want the source, I will just get it from SF
CVS.
 

---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
   



---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
 



--
Ian MacLean, Developer, 
ActiveState, a division of Sophos
http://www.ActiveState.com



---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers

Re: [nant-dev] NAnt Tag and Branch policies

[Ian MacLean]

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 making changes to the main branch. If you choose not 
to branch and the release process takes any length of time then all the 
commits waiting to go onto the main line have to be queued up. If a 
branch is made the sources should still be rtagged on that branch prior 
to release - its not really an either/or situation.

see: http://www.kagekaze.org/cvs/cvs-talk/releng/tags.html

Ian

I'm not a cvs expert, but it seems like we are not doing this correctly if
we create a branch before we make a release. We should be rtag'n and not
branch'n.
- Original Message - 
From: "Clayton Harbour" <[EMAIL PROTECTED]>
To: "Scott Hernandez" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Wednesday, November 12, 2003 7:43 PM
Subject: RE: [nant-dev] NAnt Tag and Branch policies

 





---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers

Re: [nant-dev] NAnt Tag and Branch policies

[Stefan Bodewig]

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 with them.  If you don't, well, they aren't that bad.  Just
make sure they don't live for too long.

The major problem is merging changes from one branch to another.  If a
branch is only short lived, this is no big deal.

> Stefan do you know what the Ant/Apache policy on this is ?

There is no Apache policy.  Different projects are doing very
different things.

The process for Ant is essentially to create a branch with the first
beta.  Development for the release happen on the branch, new
development goes on on the main branch.  It works, but the longer the
beta period the more pain is involved.

For more details on Ant's process, see
.

Stefan


---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers

Re: [nant-dev] NAnt Tag and Branch policies

[Ian MacLean]

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. What do other open-source projects do ? Stefan do you know 
what the Ant/Apache policy on this is ?

Ian
Scott Hernandez wrote:
I don't want branching done unless we have to. Unless there is a reason we
*need* to branch, then we should not.
We should change our release plan on the wiki.
http://nant.sourceforge.net/wiki/index.php/ReleaseProcess
Please see additional comments inline.

- Original Message - 
From: "Clayton Harbour" <[EMAIL PROTECTED]>

 

Hi Scott,

I don't mean to rattle anyone's confidence but I am not a cvs expert
either.  What I am suggesting is a way to manage the release cycle and
continue on with core feature development at the same time.
I think I understand what you are saying.  Lay down a tag and if we need
to go back to a point in time then we can branch at that tag, make any
code fixes and re-release from that point.
What I am thinking of is really quite similar, except I say that there
will be code changes so when we tag, also branch.  I think this is
reasonable because usually releases go through an RC1/RC2 cycle (from
memory I think we used this last time, please correct me if I am wrong)
which are usually prompted by bug releases.  The RC1/ RC2 would of
course be tagged on the release branch and all bug fixes would be
applied there.  Probably at the time we tag this we would merge the bug
fixes back into the trunk.
   

I understand what you are suggesting, I don't like that plan. From what I've
read, and the stories I've heard from other projects, and people who have
used, and understand, cvs much more than I do, it is best not to branch
unless there is a very good reason.
CVS is not VSS, SVN, or any other source control system. Even though all
these system work very similar in concept, there are some very serious
differences in application.
 

I realize that developers will then have to be aware of which code base
is the development trunk (or head) and which is the branch.  It will
mean two separate cvs trees locally (if you have bugs to fix, 1 if you
do not) but these can be named using the options tab in tortoise so they
should be fairly easy to manage.  It will also make the task of fixing a
bug versus refactoring a section of code explicit and should keep the
risk down for letting any additional bugs creep into the release code
base from large coding changes.
   

Why should each developer need to maintain a seperate source branch on their
local machine? If we use tags we just work from the head until we are ready
for the releases. We will still have access to those specified versions of
files based on that tag. If at any point we need to branch, we can from the
tag. :)
 

All I am saying (and please remember this is just my opinion) is that as
soon as we put up that RC1 then that is beginning our release cycle.
The code base that generated that zip file should be used during the
entire release cycle to make it stable as possible before we sign off on
an official release.  I realize that nant is still in beta but I think
we can still adopt a process that is going to help us once we go beyond
that.
   

I understand what you are going for. I think we should keep it simple and
just use tags and not branches unless we start getting serious restructuring
on code during beta/rc cycles of a release. One of the point of keeping the
list updated is that we don't have that happen, we won't see massive changes
since devs know to hold that kind of stuff off till after the release.
Yes, setting up and keeping a good process will make it easier for people to
jump in and keep things going. No question about that. :)


---
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
 



--
Ian MacLean, Developer, 
ActiveState, a division of Sophos
http://www.ActiveState.com



---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers