How to set different baseUrl path in jQuery ajax requests in development and production mode?

My baseUrl path for jQuery ajax requests is different in development and production mode. How can I set it in some kind of config.ini file to switch it easily. Rightnow I'm using a baseurl.js file containing just baseurl path. In production mode, I change this variable via shell script.

What should be better approach?

edit

To make things little clearer,

 $.ajax({
   type: "GET",
   url: myurl,
   dataType: "script"
 });

Here 'myurl' var is different for produ开发者_StackOverflow中文版ction and development.

PS: My question is not about version control or packing files into one.

---

If you are using some dynamic pages technology (asp, php, ...) then you could turn your baseurl.js file to a dynamic one like baseurl.js.php and inside it print the current url . (if that is what you are asking).

• for php look at $_SERVER
• for asp look at Request.ServerVariables

---

When deploying any sites that use more than I little JavaScript, I like to use YUI Compressor to pack all of my script files down in to a single file which then gets included on the production site, and will load much faster than if the browser had to load each file individually.

To avoid making mistakes when running it, I created a shell script containing the command line arguments for YUI, which gets run before deployment. This is also the perfect place to reference any production-specific JavaScript files - for example you could create a production.js file that sets your baseurl path and include it in the command line.

---

Using a revision control system would be the best approach.

You would have one configuration file, and each client can "check it out" and modify it at will to suit their own environment (development, testing, production, etc).

You'll probably have the production configuration committed to your revision control system, and you'll have a customized version in your development environment. Just don't check your customized version in to the revision control server.

I don't know what operating system you're on, but I would recommend TortoiseSVN (for Windows) and Beanstalk (hosted subversion service) to get up and running with minimal effort. If you'd rather setup your own SVN server, VisualSVN makes it a trivial task.

And voila, no more swapping configurations!

---

I think that having relative URLs be different in development versus production sounds like a mistake anyway. That's pretty much the advantage of relative URLs: they navigate your application structure in a way that's independent of host deployment details.