Provided link point to a problem with push and poll configuration. Using push mechanism disables poll for used repository. If One has builds divided to incremental and complete, push will trigger both. It would be nice if push and poll mechanism could be configured independently.What I like to achieve is to use push in incremental build and poll in complete build (both pointing to the same repository). So that complete builds are triggered when needed. Now Build periodically can be used but it will trigger build event if no changes where made.

I'm guessing you are talking about SVN Post commit hook. If you have set up SCM polling (you need to have that else push doesn't work) it will be always honored. The issue with pushing is, it does not know the job. So it depends on repository UUID. So it finds all the jobs which uses repository with that UUID and schedules it. Unfortunately this will end up scheduling both your jobs.

To fix this we have to introduce the notion of "push only SCM trigger" in core

Jenkins Subversion Slugin has implemented this in specific way:
Jobs on Jenkins need to be configured with the SCM polling option to benefit from this behavior (SVN post commit hook). This is so that you can have some jobs that are never triggered by the post-commit hook (in the $REPOSITORY/hooks directory), such as release related tasks, by omitting the SCM polling option.
The configured polling (on 'incremental' job) can have any schedule (probably infrequent like monthly or yearly). The net effect is as if polling happens out of their usual cycle

It is the same here but we are talking about separating pushes from polls in a way that some jobs would be triggered after push while others would not even though all of them got the same SCM repo configured