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 - >
