More flexibility in label generated

[GoogleCodeExporter]

You are so close to what I need.  We use the first 3 sections of the version 
number 
and only leave the last for the svn revision.  From what I have read the most 
common 
way to use the version number is:

major.minor[.build[.revision]]

Could you somehow allow for more customized way of creating the label.  For 
example, 
if the build attribute was defined, the label would be 7.11.23.<revision> and 
if the 
build was forced, 7.11.23.<revision> - <forced build number>

<labeller type="svnRevisionLabeller">
    <major>7</major>
    <minor>11</minor>
    <build>23<build>
    <url>svn://localhost/repository/trunk</url>
</labeller>

Or even better

<labeller type="svnRevisionLabeller">
    <major>7</major>
    <minor>11</minor>
    <build>23<build>
    <url>svn://localhost/repository/trunk</url>
    <pattern>{major}.{minor}.{build}.{revision} - {forced}</pattern>
</labeller>

And just plug in the known parts leaving the other text.  This would allow 
complete 
flexibility.  If the pattern is not specified, the current "pattern" would be 
used.

I could submit a patch if you are interested. (mike.schall <at> gmail.com)

Mike

Original issue reported on code.google.com by mike.sch...@gmail.com on 17 Sep 2008 at 10:12

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I would like to see this option as well.  In addition, I would like to option 
to not
have an auto-incremented (e.g., forced)  number.  If I force a build and there 
have
not been changes in my source, then I am effectively rebuilding a previous 
version
and I do not need or want to modify the version number.

Original comment by ryanewta...@gmail.com on 9 Feb 2009 at 1:40

[GoogleCodeExporter]

This looks to be pretty much what issue #1 is asking for
(http://code.google.com/p/svnrevisionlabeller/issues/detail?id=1), and to be 
honest,
it's what I'm after too. So I guess a new version will be forthcoming quite 
soon.

Original comment by davidkeaveny on 11 Feb 2009 at 11:40

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by davidkeaveny on 11 Feb 2009 at 11:43

[GoogleCodeExporter]

Original comment by davidkeaveny on 13 Feb 2009 at 5:44

• Changed state: Started
• Added labels: Type-Enhancement, Priority-High
• Removed labels: Type-Defect, Priority-Medium

[GoogleCodeExporter]

I've started work on option A, as option B probably requires a fair amount of 
work.
However, if you want to get involved, please feel free to submit a patch, and I 
can
add it in.

Original comment by davidkeaveny on 13 Feb 2009 at 6:59

[GoogleCodeExporter]

Option B wouldn't be that much of a problem when creating a CustomFormatter to 
do the
work.
It might not look like the suggested pattern, but rather familiar to 
string.Format:

<pattern>Test{0:Prefix} {0:Major}.{0:Minor}.{0:Revision}.{0:Build}</pattern>

Implement ICustomFormatter and IFormatProvider to provide formatting stuff.
Generate then returns string.Format(this, pattern, newVersion, 
resultFromLastBuild);
(I am currently playing around with all the things the last build tells me, 
hence the
second parameter).

Format checks for various conditions you might want:
public string Format(string format, object arg, IFormatProvider formatProvider)
{
    Version v = arg as Version;
    IIntegrationResult lastResult = arg as IIntegrationResult;

    if (!string.IsNullOrEmpty(format))
    {
        switch (format.ToLower())
        {
            case "major":
                return (v != null ? v.Major : Major).ToString();
            case "minor":
                return (v != null ? v.Minor : Minor).ToString();
            case "revision":
                return (v != null ? v.Revision : 0).ToString();
            case "build":
                return (v != null ? v.Build : 0).ToString();
            case "modifications":
                return (lastResult != null ? lastResult.Modifications.Length :
0).ToString();
        }
    }
    return Convert.ToString(arg);
}

I attached a patch file, but I think you might have to tweak it here or there in
order have it fit your needs; different indentation might break the patch aswell
(company guidelines, sorry). Note that I also took the liberty of swapping the 
build-
and revision-parameters of the Version class to match the parameters actual 
meaning.

Original comment by j4ck.fr0st@gmail.com on 19 Feb 2009 at 8:05

Attachments:

• SvnRevisionLabeller.patch

[GoogleCodeExporter]

Argh.
Makes sense to test it first. The default Pattern is wrong, printing it 
literally
rather than using it as format. Use single curly Brackets to fix that.

Original comment by j4ck.fr0st@gmail.com on 19 Feb 2009 at 8:17

[GoogleCodeExporter]

First, thanks to David for getting this plugin going! I found both it and
ccrevisionlabeller (http://code.google.com/p/ccrevisionlabeller) which is 
derived
from David's code, but neither quite did what we needed. 

I've created a version which adds the following features which seem to align 
with
what some are asking:
* defaults to use the Microsoft recommended versioning format
* option to increment the build number always, similar to DefaultLabeller 
[default:
false]
* option to reset the build number to 0 after a (major/minor) version change
[default: true]
* "pattern" property to support user-defined build number format
* option to include a postfix on version

Any questions or comments are welcomed.

Original comment by fezguy@gmail.com on 19 Feb 2009 at 8:47

Attachments:

• SvnRevisionLabeller.cs

[GoogleCodeExporter]

Wow, thanks for all the patches, guys! I'll have a look at j4ck.fr0st's patch 
next 
week (this week is caught up with Real Life at work *grin*).

Original comment by davidkeaveny on 19 Feb 2009 at 9:34

[GoogleCodeExporter]

After checking out the desires of Mike Schall et at, I have added an option for
forced build number ("rebuild"). I also forgot to mention last time that 
Subversion
URLs with spaces were also handled as of my first post.

David, if you care for these features, I can create a patch for you. However, 
I've
done a bunch of refactoring in various places, esp. making use of .NET v3.0's
automatic properties.

I have also created a test script (MSTest) to do unit testing. It requires 
another
few DLLs (ThoughtWorks.CruiseControl.Remote.dll, NPlot.dll, log4net.dll), and a
little threading to facilitate CCNET's plugin structure.

Updated feature list:
* defaults to use the Microsoft recommended versioning format
* option to increment the build number always, similar to DefaultLabeller 
[default:
false]
* option to reset the build number to 0 after a (major/minor) version change
[default: true]
* "pattern" property to support user-defined build number format
* handles an additional "rebuild" field via "pattern" property which counts 
builds of
same revision
* option to include a postfix on version
* handles Subversion URLs with spaces

Original comment by fezguy@gmail.com on 20 Feb 2009 at 1:00

Attachments:

• SvnRevisionLabeller.cs

[GoogleCodeExporter]

We may have to hold off on the .NET 3.x-specific features, as not everyone will 
necessarily be running in that environment. .NET 2.0 should be fine, as CC.NET 
is 
built against it (although so far it only takes a recompile to add .NET 1.1 
support). 
Perhaps I should create some NAnt scripts to build the various flavours :-)

Original comment by davidkeaveny on 20 Feb 2009 at 1:05

[GoogleCodeExporter]

Automatic Properties (aswell as Lambdas, the yield Statement, and Type 
Inference) are
just "Syntactic Sugar" added by the C#3.0 Compiler (that ships with Visual 
Studio
2008). Since it can build against the .Net 2.0 Framework too (same Runtime at 
all),
you can also use those features there. Linq and other Technologies wont work 
tho.

CCRevLabeller sounds interresting, aswell as fezguy's part - the version I made 
does
what I want, but it's still nice to know that people always work to improve 
things. :)

Original comment by j4ck.fr0st@gmail.com on 23 Feb 2009 at 7:32

[GoogleCodeExporter]

I've merged in fezguy's change, as it seems to contain the most functionality. 
It 
builds fine, and CC.NET generates labels OK for me. I want to work on getting 
some 
unit tests in there, as well as on the documentation, as this is a breaking 
change to 
the functionality of the labeller.

Please feel free to check out the latest revision and build it yourself 
(against 
VS2008 only, since the automatic properties are in there, although as 
j4ck.fr0st 
points out, the compiled assembly should still run on .NET 2.0).

Many thanks for the contribution, fezguy - this should make this labeller more 
useful 
to the CC.NET/SVN community.

Original comment by davidkeaveny on 27 Feb 2009 at 6:26

[GoogleCodeExporter]

Thanks David. Let me know if you need any help with anything (documentation, 
tests,
etc.); I'd be happy to help.

Original comment by fezguy@gmail.com on 4 Mar 2009 at 9:28

[GoogleCodeExporter]

Original comment by davidkeaveny on 19 May 2009 at 1:08

• Changed state: Fixed