Jan Hauke Rahm a scris: > Hi Eddy, > > On Fri, Nov 28, 2008 at 06:49:46PM +0200, Eddy Petrișor wrote: >> OTOH, if failing can be avoided (svn add --no-ignore everything except >> .svn dirs), I think that is preferable. >> >> So, since using "svn add --no-ignore" would yeld the same results for >> interactive for as for noninteractive builds and avoids creating a prompt, >> I think that we should investigate into that option. > > Okay, I figured out something different, patch is attached. > It's now simply printing a note about files being ignored and tries to > add them via the SVN::Client connection. > > What would you say?
That sounds sane, but it seems you forgot to attach the patch (the second time) and since the current one is outdated, makes sense for me to wait :-) . >>> Off topic: Why is that line >>> return 1 if ($SDCommon::opt_ignoreerrors); >>> in sub withechoNoPrompt? As far as I can see (and debug) that means that >>> no command is executed when noninteractive and ignoreerrors are set. It >>> just returns 1. That pretty much looks like a bug, doesn't it? (I'm >>> becoming more cautious) >> No, it makes noninteractive builds not fail on errors which otherwise would >> have >> stopped the build when --svn-ignoreerrors is passed. > > I see the idea but I don't see the command being executed in that case. > See the lines around it: > > ,---- > | print STDERR "$cmd\n" if(!$SDCommon::opt_quiet); > | return 1 if ($SDCommon::opt_ignoreerrors); > | return (!system(@_)); > `---- That is the whole point, there are some prompts that aren't critical for successful building the package in an automated environment (e.g.: things like being unable to automatically upgrade a package when no upstream release was done - i.e. the version is the same in upstream as in our repo) but still are an abnormal situation. There are several such cases where an abnormal situation should just be ignored for automated builders or similar automated tools. In a better implementation, we would rather have prompts with a default answer preselected in case of failure so, depending on the thing that failed, svn-bp would ignore by default or quit by default. Ideally, it would be nice to have the possibility to specify which individual commands would be OK to fail (and be ignored) by some sort of configuration in ~/.svn-buildpackage.conf. In other words, for a setup which tries periodically operations that may fail regularly in certain spots, the conf file would specify those particular commands (or groups). But, in the end, I really think we should provide some mechanism to hardcode a default answer in case of non-interactive builds for each question and a way to override that. Just to make things clear with an example. Suppose: - you have an upstream which releases .tar.bz2 files so you have to repackage to .tar.gz - your upstream might add undesired files in the package, but you have to check them individually - you have an automated builder which tries to update your package in the repo as soon as upstream releases; that builder sends you an email with the log for that operation Now, a new upstream comes along with a .swp file in it. Your builder should simply ignore the file and not include it in the repackaged source since you'd check the log anyway, so is OK for it to ignore the new file and let the builder try to build the new package. If you didn't had any way to specify that you want to ignore new files by default, your builder would choke by default and fail to help you. > the actual system call wouldn't be executed with ignoreerrors set, or am > I missing something here? No, you are correct. It is just that the granularity of the option is too coarse since is either "ignore all" or "fail on the first error". > PS: Sorry for not commiting the other thing; I was not at home this > weekend. Thanks for doing that! no problem -- Regards, EddyP ============================================= "Imagination is more important than knowledge" A.Einstein
signature.asc
Description: OpenPGP digital signature
