I think synchronizing things in a "per job" way will become very complex.
Moreover, don't see the scm-sync-configuration plugin as a "job only" backup. Aim is to backup lots of other entities (like global hudson system properties, plugin configurations, views, users etc..)

For me, it is a really job specific stuff, I won't prioritize this for the moment.

Nevertheless, on the 2 way sync topic, if you read http://wiki.jenkins-ci.org/display/JENKINS/SCM+Sync+configuration+plugin, you'll notice this functionality is in my todo list.
For me, there is 2 different use cases :

• Provide a "commit history" on the current configuration file, allowing to see who/why commit occured on the configuration file. Ideally, this screen could detect a "current configuration file is not up-to-date" (if commited on the SCM by someone else than current hudson instance) and allow to update current configuration file.
• Provide a "mirroring" functionality allowing to "auto update" commit on files regularly (very useful, for instance, when we are using a hudson production environnement, mirrored with a "pre-production" hudson environnment).

For the auto import jobs functionality, this is for me, too, a target objective. Allowing to create some job archetypes for my projects, and import massively them in hudson.

All described features are really nice.
As for "per job" - I guess for now we can try do some hacky solution using svn externals.

From my point of view, the job specific URLS are not that important. I was thinking about it to, but in my case I rather have everything in one place than to hunt in different projects for my Hudson configuration (1. separation of concerns; 2. high maintenance to deny developers write access to Hudson config in SVN).

I also see the creation of a Hudson job from a branch as an highly specialized use case with difficulties to implement general rules for discovery of a new job in svn, whereas the creation of a new job from a centralized place in SVN (all job configs stored together) is way easier (from the perspective of discovering a new job config). (On easy way to implement the job discovery is to mark jobs with a SVN property. So only URLs that contain the job property will trigger the creation of a new job.

The issue of automatically triggering a build, when the job config changes, is in my opinion irrelevant as long as you do all the job changes manually, since you just hit the build button after you did you changes.

When I have major changes to a job, I usually save the job config several times before I run a test build. If I do everything in one big change, I tend to loose changes to often, due to my clumsy way to use browsers.

I think a really nice feature is the synchronizing Hudson with SVN. U hope it is possible to change the config of one job without triggering the config reload on server level.

FYI, I have in my todo list (http://wiki.jenkins-ci.org/display/JENKINS/SCM+Sync+configuration+plugin) a functionality allowing the user to check "don't bother me during XXX minutes" in the commit message prompt.

If checked, message prompt won't reappear (obviously for the current job only) until XXX minutes.
Particularly useful if, as you say, you're playing with your job configuration and trying to enhance a build execution.
I admit in these particular case, the commit message prompt is really too intrusive for the user.

For all the other cases, my point of view is the commit message prompt is a good reminder to detail what has just be done.

The commit message would bother me less than the effect, that my build job runs several times before I am done with my configuration work (the implementation that pancake was asking for). Especially, since some of my jobs take 15 minutes and longer and might also trigger other jobs to be build. So the don't bother me is currently nothing of concern for me.

After thinking about what was said before about triggering a job when only the job config changed. You don't need to bother about it. For Subversion you can configure exceptions, that don't trigger a job. I think this is more an SCM issue that an scm-sync-plugin issue. Another example of the same issue is updating the build number and commiting back to the scm. You don't want to have a build triggered than either.

I put the synchronization of the configs in a separate issue, to discuss the implementation of the ToDo list item.

fcamblor mentioned that it is complex to have the scm path dependent on the job. I can only come up with one solution, which would be to store a separate synchronization URL on every job. If non is configured the main URL will be used. If the job URL changes, the configuration will be moved to the new location in SCM.

This will also solve the automatic creation of a job. See following workflow.
1. read config from scm
2. check scm sync url for new job, if it exists, move config in scm.
3. create job.

I vote for not implementing pancake's logic for the scm URL, since it is highly specific. The next user will come up with a slightly different solution.

If pancake needs an easy way of using a job template, I would vote for implementing the use of job variables to calculate the job URL. In this case you can change the job name and the job will move in the SCM. This would make it necessary to store the variables used in the URL every time, the job config is commited to the scm.