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