Great, I think we have reached some kind of consensus now. I will look into creating a new patch using the TortoiseSVN client. The LastChangeLabeller behavior will be:
With prefix="pre" and allowDuplicateSubsequentLabels=false: pre1234.1 pre1234.2 pre1235.1 ->change configuration file and set prefix="new", then trigger a forced build without modifications pre1235.2 new1236.1 new1236.2 With prefix="pre" and allowDuplicateSubsequentLabels=true: pre1234 pre1234 pre1235 ->change configuration file and set prefix="new", then trigger a forced build without modifications pre1235 new1236 new1236 To minimize the impact on existing projects, allowDuplicateSubsequentLabels=true will be the default behavior. //P-J 2009/2/18 [email protected] <[email protected]> > > Well, I'd like to thank you to you guys for bringing this back up > again. I did find the patch for lastchangelabeller on the developers > forum, but Im unsure of how to implement it. All I need it for > lastchangelabeller to stop throwing an unknown if there is no > transactions between builds. > I think my requirements are similiar to Shauns....having it increment > with a xxx.1 xxx.2 is fine by me. > > On Feb 18, 6:51 am, Ruben Willems <[email protected]> wrote: > > Hi... > > > > read more » > > > > 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 <- Hide quoted text > - > > > > - Show quoted text -
