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 -
