Hi
just sparsely following this discussion
each labeler stands on its own, thre is no reletion between 2 labellers.
the more the labellers act the same in a given situation, the better of
course,
but this does not have to be. If there is a good reason, why not do it.
there is a big change between the datalabeller and the default labeller ;-)
Do keep in mind that when you make a breaking change, is not fun.
So try to keep the existing default behaviour if possible.
Adding extra properties is not a problem, as long as this doe snot result in
stuff like this
bool UseNewSetup
and than somewhere in code
if (UseNewSetup)
{
bla bla
}
in this case it would make more sense to create a new labeller with the
desired behaviour
my 2 cents
with kind regards
Ruben Willems
On Wed, Feb 18, 2009 at 12:29 PM, Per-Jonny Käck <[email protected]> wrote:
> I can agree with you that either forcing .nnn for all labels, or pre1234
> followed by pre1234.2 would be more logical.
> It's just that the FileLabeller is implemented as pre1234 followed by
> 1234-1.
> And lukes propsed patch seems to follow the same scheme.
> The question is if it is better have a consistent behavior between the
> label implementations, or a logical implementation of the LastChangeLabeller
> only???
> Is there any CruiseControl.NET developer that has an opinion?
>
> //P-J
>
> 2009/2/18 CinnamonDonkey <[email protected]>
>
>
>> Sounds good to me P-J,
>>
>> The only comment I would have but it's just me being pedantic now is
>> that if the labeller is allowing the post fix of '.nnn' then all
>> labels should follow the same scheme:
>>
>> pre1234.1
>> pre1234.2
>> pre1235.1
>>
>> ...and not:
>>
>> pre1234
>> pre1234.1
>> pre1235
>>
>> ...as this does not seem logical to me. At the very least it should
>> be:
>>
>> pre1234 (<-- is effectively pre1234.1 as it was the first
>> build with the label 1234)
>> pre1234.2
>>
>> Like I say, I'm just being pedantic.
>>
>> Shaun ;-)
>>
>>
>>
>>
>> On 18 Feb, 10:48, P-J <[email protected]> wrote:
>> > Yes, we are talking about the same thing concerning duplicate labels.
>> >
>> > About my next paragaraph, it only applies if you have specified a
>> > prefix.
>> > Let's say you are currently using the string "pre" as prefix, and you
>> > have set AllowDuplicateSubsequentLabels=true for our new
>> > LastChangeLabeller.
>> > Using your examples, the labels would look like this:
>> > pre1234
>> > pre1234
>> > pre1235
>> > At this point change your configuration file and set the label prefix
>> > to the string "new", then force a new build without modifications, and
>> > the labels will be as follows.
>> > pre1235
>> > new1236
>> > new1237
>> >
>> > With AllowDuplicateSubsequentLabels=False the labels would be:
>> > pre1234
>> > pre1234.1
>> > pre1235
>> > At this point change your configuration file and set the label prefix
>> > to the string "new", then force a new build without modifications, and
>> > the labels will be as follows.
>> > pre1235.1
>> > new1236
>> > new1237
>> >
>> > Personally I think this behavior would be ok, i.e. that the change of
>> > the prefix will not be visible until you have a new build with
>> > modifications.
>> > The good thing is about this solution is that it is easy to use and
>> > understand, and doesn't restrict your choice of prefix in any way.
>> >
>> > //P-J
>> >
>> > On 18 Feb, 11:29, CinnamonDonkey <[email protected]>
>> > wrote:
>> >
>> > > Hi P-J,
>> >
>> > > Adding a new attribute, "AllowDuplicateSubsequentLabels" sounds like a
>> > > good plan as it allows more flexibility to the end user and satisfies
>> > > my own requirements.
>> >
>> > > I'm not sure I fully understand the next paragraph, but I think we are
>> > > talking about the same thing.
>> >
>> > > If I can end up with:
>> >
>> > > 1234
>> > > 1234
>> > > 1235
>> > > 1235
>> > > 1236
>> > > 1237
>> >
>> > > I'll be a very happy chappie, but I could live with:
>> >
>> > > 1234.1
>> > > 1234.2
>> > > 1235.1
>> > > 1235.2
>> > > 1236.1
>> > > 1237.1
>> >
>> > > If it was a necessary compromise but I think the post fix should be
>> > > optional.
>> >
>> > > Shaun
>> >
>> > > On 18 Feb, 08:25, Per-Jonny Käck <[email protected]> wrote:
>> >
>> > > > Ok, then a "AllowDuplicateSubsequentLabels" attribute (e.g. used by
>> the
>> > > > FileLabeller) should be added to lukes patch, since his patch always
>> > > > increments the latest label.
>> >
>> > > > Do you have any problems with that if you change the prefix in your
>> > > > configuration file, then you won't see the new prefix until there is
>> a new
>> > > > build with modifications, since builds without modifications will be
>> > > > labelled based on the last label. I think this behavior would be ok,
>> and it
>> > > > makes the source code much cleaner.
>> >
>> > > > //P-J
>> >
>> > > > 2009/2/18 CinnamonDonkey <[email protected]>
>> >
>> > > > > Our requirement is that each build is labelled with the change
>> list
>> > > > > number (we use Perforce) used to create that build. This means
>> that we
>> > > > > can relate any particular build directly back to a specific point
>> in
>> > > > > the source history. Anything else is meaningless.
>> >
>> > > > > Since the change list numbers are unique an represent a particular
>> > > > > moment in time this should be perfectly possible.
>> >
>> > > > > - If a modification exists use the highest retrieved
>> modification
>> > > > > change list number.
>> > > > > - If no modifications exist, we must still be on the same
>> > > > > modification change list number.
>> >
>> > > > > Duplicated labels should be valid as the build date/time stamp is
>> used
>> > > > > to reflect the exact identity of that build. The label correlates
>> the
>> > > > > build with the source.
>> >
>> > > > > For us anyway (everyone's requirements are different ;).
>> >
>> > > > > Regards,
>> > > > > Shaun
>> >
>> > > > > On 18 Feb, 08:04, P-J <[email protected]> wrote:
>> > > > > > This is still an issue on the latest build.
>> > > > > > The LastChangeLabeller is not good enough, and requires a patch.
>> >
>> > > > > > The problem has also recently been mentioned e.g. in the
>> following
>> > > > > > ccnet-user threads:
>> > > > > > "<LastChangelabeller> :Accurev/CCNET error: Given Update...".
>> > > > > > "LastChangeLabeller issue in case of a forced build with no
>> changes in
>> > > > > > SVN"
>> > > > > > "LastChangeLabeller and Unknown with Accurev"
>> >
>> > > > > > A patch has been submitted by luke to ccnet-devel, thread
>> "Improving
>> > > > > > the LastChangeLabeler".
>> > > > > > His patch appends a ".1" or increment an existing integer to the
>> last
>> > > > > > label, instead of creating an "unkown" label.
>> > > > > > Is this good enough for everyone? In this patch:
>> > > > > > - If you change the Prefix in your config file, and then make a
>> forced
>> > > > > > build with no modifications, then his patch will return an
>> incremented
>> > > > > > label with the old prefix. Is this ok?
>> > > > > > - There is no "AllowDuplicateSubsequentLabels" to choose if you
>> only
>> > > > > > want the LastChangeLabeller to return the latest label, or if
>> you want
>> > > > > > it to return the latest label with an incremented suffix.
>> >
>> > > > > > What do you want?
>> > > > > > I would be happy to contribute if could just get this into the
>> trunk!
>> >
>> > > > > > Regards,
>> > > > > > //P-J
>> >
>> > > > > > On 10 Feb, 21:31, "[email protected]" <
>> [email protected]>
>> > > > > > wrote:
>> >
>> > > > > > > Hey thanks for the response. To be clear:
>> >
>> > > > > > > I am using the "lastChangeLabeller" with the Accurev source
>> control
>> > > > > > > system. And I have noticed the EXACT issue: That if a build
>> process is
>> > > > > > > triggered and "No
>> > > > > > > Modifications" are detected. The labeller labels the build as
>> > > > > > > "UNKNOWN".
>> > > > > > > Another wrinkle: because Im doing snapshots of each build,
>> that name
>> > > > > > > 'unknown' is already being used, and the build fails.
>> > > > > > > I agree that, "if no modifications are detected, then the
>> label should
>> > > > > > > simply
>> > > > > > > remain unchanged and be what it was for the previous build"
>> > > > > > > Or something unique (iterative).
>> > > > > > > This is a show stopper for me. If I cant fix it, we will have
>> to
>> > > > > > > change the tagging and labeling to date based, I'd rather keep
>> it
>> > > > > > > transaction based.
>> >
>> > > > > > > Is there a way around this?
>> >
>> > > > > > > Im using CCNET version : 1.4.0.3524
>> > > > > > > Id appreciate if someone could share a workaround/fix or
>> definitely
>> > > > > > > tell me I have to suck it up and upgrade.
>> >
>> > > > > > > thanks,
>> > > > > > > Russ
>> >
>> > > > > > > On Feb 10, 3:13 am, CinnamonDonkey <
>> [email protected]>
>> > > > > > > wrote:
>> >
>> > > > > > > > I'm affriad I still haven't tried this out yet.
>> >
>> > > > > > > > I was hoping for 1.4.3 to be released before I do any
>> upgrades.
>> > > > > Having
>> > > > > > > > made so many changes to my installation I want to minimise
>> the
>> > > > > numbert
>> > > > > > > > of times I do upgrades.
>> >
>> > > > > > > > Shaun
>> >
>> > > > > > > > On 9 Feb, 21:23, "[email protected]" <
>> [email protected]>
>> > > > > > > > wrote:
>> >
>> > > > > > > > > I have a similiar problem as well.
>> >
>> > > > > > > > > On Feb 9, 11:14 am, P-J <[email protected]> wrote:
>> >
>> > > > > > > > > > What's the status on this? I have the same problem.
>> >
>> > > > > > > > > > When theLastChangeLabellerstarts to remember the last
>> label, it
>> > > > > > > > > > would also be a good idea to add the
>> > > > > "AllowDuplicateSubsequentLabels"
>> > > > > > > > > > property and suffix functionality from the FileLabeller.
>> >
>> > > > > > > > > > //P-J
>> >
>> > > > > > > > > > On 2 Feb, 11:09, CinnamonDonkey <
>> [email protected]>
>> > > > > wrote:
>> >
>> > > > > > > > > > > Thank you for the quick response Ruben.
>> >
>> > > > > > > > > > > I'll check out the latest build.
>> >
>> > > > > > > > > > > On 2 Feb, 10:05, Ruben Willems <
>> [email protected]>
>> > > > > wrote:
>> >
>> > > > > > > > > > > > Hi
>> >
>> > > > > > > > > > > > can you simulate this with the latest build
>> > > > > > > > > > > > see previous mail
>> >
>> > > > > > > > > > > > with kind regards
>> > > > > > > > > > > > Ruben Willems
>> >
>> > > > > > > > > > > > On Mon, Feb 2, 2009 at 10:46 AM, CinnamonDonkey <
>> >
>> > > > > > > > > > > > [email protected]> wrote:
>> >
>> > > > > > > > > > > > > Hi All,
>> >
>> > > > > > > > > > > > > I am using the "lastChangeLabeller" with our
>> Perforce
>> > > > > source control
>> > > > > > > > > > > > > system. I have noticed that if a build process is
>> triggered
>> > > > > and "No
>> > > > > > > > > > > > > Modifications" are detected. The labeller labels
>> the build
>> > > > > as
>> > > > > > > > > > > > > "UNKNOWN".
>> >
>> > > > > > > > > > > > > Surely, if no modifications are detected, then the
>> label
>> > > > > should simply
>> > > > > > > > > > > > > remain unchanged and be what it was for the
>> previous build?
>> >
>> > > > > > > > > > > > > Is there a way around this?
>> >
>> > > > > > > > > > > > > Regards,
>> > > > > > > > > > > > > Shaun- Hide quoted text -
>> >
>> > > > > > > > > > - Show quoted text -- Hide quoted text -
>> >
>> > > > > > > > - Show quoted text -- Dölj citerad text -
>> >
>> > > > > > > - Visa citerad text -
>>
>
>
