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 -
