On Thu, 2006-12-07 at 23:07 +0100, Anna / Marek Latuskiewicz wrote: > >> - the feature around label_name - is there any specific reason that > >> scmbuga > >> assumes the directory must be in root - ie. /branch /tags, not > >> /project_name/branch & /project_name/tags > > > > If scmbug assumes, somewhere, the directory must be in root, it's > > probably a limitation of some original design; and should be lifted. It > > seems that SCM_Functions.pm.in:get_label_date suffers from this (used by > > the VDD Generator). Have you found other places ? > > > > We should fix this, yes. > OK - but it can be fixed in config files - All you have to do is to play > with regex: > > label_directories => [ > 'tags', > 'branches' > ], > > > > ex. you just need to add -all tags in the second level > > '[^/]*/tags > The pros is that you have the complete control of where you are looking for > so there is no constraints to for examples 'tags' subdirectores deep within > the project.
This breaks automatic product name detection. > > You need also to change naming rules - for ex. > > '^.+?_RELEASE_[0-9]+-[0-9]+-[0-9]+$', > > > > to: > > '^.*?_?RELEASE_[0-9]+-[0-9]+-[0-9]+$', > > > > as there is no need to name build within the directory. > > Therefore we need to change default config templates only.... > > > > > > > http://bugzilla.mkgnu.net/show_bug.cgi?id=893 > > > > For example, we should require the user to supply in both the VDD > > Generator and the Merger a label name like "project_name/tags/sometag" > > instead of just "sometag". So while you are implementing the Merger, > > assume the bigger label name, and I'll take care of fixing the VDD > > generator. > > > > How does this sound ? > OK - how about proposed solution in config file? Looks fine for me... I believe it comes down to the fact that we want to have the capability of automatically detecting "product_name1" and "product_name2" in paths like: product_name1/trunk product_name1/branches product_name2/trunk product_name2/branches /trunk/product_name1 /trunk/product_name2 /branches/product_name1 /branches/product_name2 > >> - what do you think of declining any updates in tags by scmbug? > > > > That's a great idea. It was recommended in the past: > > > > http://bugzilla.mkgnu.net/show_bug.cgi?id=859#c4 > > > > When 859 is implemented you would be able to somehow mark tags as > > "closed/frozen" branches in which new commits would be disallowed. > > It proposes a stricter control I thought - the problem I see is that we > would duplicate some of the functionality of 'auth' file within subversion. I don't know how that file works. But cases (2),(3),(4) would still have to be implemented. > Don't you think? Do we have an infrastructure to analyze this file from > scmbug? I doubt this file has the notion of "it's required to supply a bug id". Or any other file in any other SCM system. It seems that we need to implement this regardless. > I reckoned to implement only something like this in the configuration : > > frozen_directories => [ > 'tags' > ], > > + small changes in perl scripts It could work. It could also work, as David pointed out, if (4) was a special case of (3) in the link above. I feel it would be simpler as David proposed, since we still have to do the work for (2),(3),(4). _______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
