Designing relative paths on development win server?
Moderator: General Moderators
- seodevhead
- Forum Regular
- Posts: 705
- Joined: Sat Oct 08, 2005 8:18 pm
- Location: Windermere, FL
Designing relative paths on development win server?
Hey guys,
Well... finally I created a development WAMP (windows, apache, mysql, php) test server on my XP Pro machine here. I have never developed/tested in a local environment, so this is completely new to me.
Question:
Should I now start developing everything (php, html, etc) with relative links only? Up till now, I have only ever used absolute paths/URL's for just about everything and am suffering now trying to make the necessary changes so it can all work on my local machine.
Is there anything bad about using relative paths/urls? Or is this the standard procedure when you develop locally then upload remotely.
Last Question:
How many of you guys do all your testing locally on your machine? Up till now, I have always developed on my machine then uploaded the file after every change, then tested from the remote server... slower process. Thanks for your help.
Well... finally I created a development WAMP (windows, apache, mysql, php) test server on my XP Pro machine here. I have never developed/tested in a local environment, so this is completely new to me.
Question:
Should I now start developing everything (php, html, etc) with relative links only? Up till now, I have only ever used absolute paths/URL's for just about everything and am suffering now trying to make the necessary changes so it can all work on my local machine.
Is there anything bad about using relative paths/urls? Or is this the standard procedure when you develop locally then upload remotely.
Last Question:
How many of you guys do all your testing locally on your machine? Up till now, I have always developed on my machine then uploaded the file after every change, then tested from the remote server... slower process. Thanks for your help.
- seodevhead
- Forum Regular
- Posts: 705
- Joined: Sat Oct 08, 2005 8:18 pm
- Location: Windermere, FL
#1
Relative paths are the way to go because its portable. You can however generate absolute paths in the final html source using PHP if you prefer, but its important that your code is portable. It really sucks having to work on a site and then have the URL change and finding yourself doing search and replace on 350 kajillion files.
#2
Its good to develop on a test server and then upload to production and test one more time. It doesn't matter if that test server is your local pc or a remote test server, but coding on a live server is always a bad idea even. I will work on a project for hours at a time on a dev server then move it to live and test it some more. One that that helps is if both web server setups are as close as possible to each other.
I don't think its that much slower, you don't have to work on only one file at a time.
#3
You skipped this one. Yes you want to use version control, I suggest subversion.
Relative paths are the way to go because its portable. You can however generate absolute paths in the final html source using PHP if you prefer, but its important that your code is portable. It really sucks having to work on a site and then have the URL change and finding yourself doing search and replace on 350 kajillion files.
#2
Its good to develop on a test server and then upload to production and test one more time. It doesn't matter if that test server is your local pc or a remote test server, but coding on a live server is always a bad idea even. I will work on a project for hours at a time on a dev server then move it to live and test it some more. One that that helps is if both web server setups are as close as possible to each other.
I don't think its that much slower, you don't have to work on only one file at a time.
#3
You skipped this one. Yes you want to use version control, I suggest subversion.
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
You can't survive without subversion, it's bog easy to setup locally (even on Windows using TortoiseSVN) if you don't want or need an online repository. Just keep regular backups! If you do use subversion, grab external libraries from their own tagged repositories using svn:externals - the SVN book is a free download if you want to check it out.
In PHP, relative pathing is best used by manipulating the include_path and for libraries using a standard naming convention like PEAR. In HTML it's even simpler - just keep in mind your app's webroot. Some PHP structures which include redirects and forwarding can change the webroot that's prepended to relative paths.
In PHP, relative pathing is best used by manipulating the include_path and for libraries using a standard naming convention like PEAR. In HTML it's even simpler - just keep in mind your app's webroot. Some PHP structures which include redirects and forwarding can change the webroot that's prepended to relative paths.
- seodevhead
- Forum Regular
- Posts: 705
- Joined: Sat Oct 08, 2005 8:18 pm
- Location: Windermere, FL
Thanks for the advice guys...
I have never heard of Subversion and have spent the past 20 mins trying to learn as much about it as possible...
Problem is... it seems more complicated than LAMP combined!!!
What kind of learning curve am I looking at to implement something like tortoise subversion? I'd love to have it, but it just seems way to heavy for me right now.
Anyone willing to take a shot at explaing what subversion can do for me in the most simplistic lamens terms possible? I am halfway through the intro on the subversion eBook and it is all over my head. Thanks a bunch guys.
I have never heard of Subversion and have spent the past 20 mins trying to learn as much about it as possible...
Problem is... it seems more complicated than LAMP combined!!!
What kind of learning curve am I looking at to implement something like tortoise subversion? I'd love to have it, but it just seems way to heavy for me right now.
Anyone willing to take a shot at explaing what subversion can do for me in the most simplistic lamens terms possible? I am halfway through the intro on the subversion eBook and it is all over my head. Thanks a bunch guys.
- feyd
- Neighborhood Spidermoddy
- Posts: 31559
- Joined: Mon Mar 29, 2004 3:24 pm
- Location: Bothell, Washington, USA
Just like any other version control system it allows you to maintain a central repository for getting the most up to date files for your development. Unlike many other version control systems, Subversion is atomic, meaning any file changing affects everything so you will know immediately if any of your code is out of date. Secondly, Subversion is one of the few that supports actual version control of binary files. Most competitors simply store the binary file. It can't tell you, contextually, what's changed between binary files most often, but it can certainly alert you to an actual change.
Subversion is pretty simple to set up as a server. Even on Windows.
Subversion is pretty simple to set up as a server. Even on Windows.
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
It's very simple - don't let the long winded book fool you
.
Basically it sets up a central store for a set of files. These files are "imported" and labelled version 1 (revision 1 or r1 in svn terms). You then "checkout" the files to your "working directory" which where you intend using and editing the files for your application. Once you make a discrete set of changes (basically commit regularly after a specific task), you then "commit" those changes to the repository. This becomes r2. 7 days later you realise the past 2 days of work is total crap, and you want to return to r45 (example) where you felt you were on track before screwing up. Since subversion tracks all changes, for every single commit, for every files (it even remembers deleted files) and uses a revision system - you simply "checkout" at r45 (yep you can grab any past revision!) or do a reversal back to r45 for the whole application if you know for certain everything from r45 to HEAD (the newest revision) is a total loss.
If you followed that, it explains itself - it makes sure you lose nothing over the history of an application. All files are stored, versioned and can be resurrected or viewed at any previous point in time.
The other main advantage is collaboration. If two or more developers are working on the same application, from a local dev server, then they can "commit" all their changes to the central repository. These will be "merged" with any changes you make so long as the developer has been keeping their working copy "updated" (when collaborating it's good to update from the central repository regularly so you can be sure your working copy always has everyone else's changes.
They be the basics - lots of other advanced stuff like creating branches (for experimental code you might want to "merge" into the main code in the future), and tags. Both are extremely useful once you master the basics. These are all picked up quickly - subversion isn't all that difficult once you understand why its so essential when developing in a group, or as an individual. Just remember keeping backups of the repository is essential since working copies are just mirrored files with non-committed edits (just a checkout away).
Basically it sets up a central store for a set of files. These files are "imported" and labelled version 1 (revision 1 or r1 in svn terms). You then "checkout" the files to your "working directory" which where you intend using and editing the files for your application. Once you make a discrete set of changes (basically commit regularly after a specific task), you then "commit" those changes to the repository. This becomes r2. 7 days later you realise the past 2 days of work is total crap, and you want to return to r45 (example) where you felt you were on track before screwing up. Since subversion tracks all changes, for every single commit, for every files (it even remembers deleted files) and uses a revision system - you simply "checkout" at r45 (yep you can grab any past revision!) or do a reversal back to r45 for the whole application if you know for certain everything from r45 to HEAD (the newest revision) is a total loss.
If you followed that, it explains itself - it makes sure you lose nothing over the history of an application. All files are stored, versioned and can be resurrected or viewed at any previous point in time.
The other main advantage is collaboration. If two or more developers are working on the same application, from a local dev server, then they can "commit" all their changes to the central repository. These will be "merged" with any changes you make so long as the developer has been keeping their working copy "updated" (when collaborating it's good to update from the central repository regularly so you can be sure your working copy always has everyone else's changes.
They be the basics - lots of other advanced stuff like creating branches (for experimental code you might want to "merge" into the main code in the future), and tags. Both are extremely useful once you master the basics. These are all picked up quickly - subversion isn't all that difficult once you understand why its so essential when developing in a group, or as an individual. Just remember keeping backups of the repository is essential since working copies are just mirrored files with non-committed edits (just a checkout away).
- seodevhead
- Forum Regular
- Posts: 705
- Joined: Sat Oct 08, 2005 8:18 pm
- Location: Windermere, FL
Wow... Tigris should really give you guys a contract to be their copywriters...lol. Now I fully understand what it does and, more importantly, how bad I need this! I'm really excited about using this.
Now, I'm looking at Subversion and I'm guessing a windows spin-off called TortoiseSVN... should I just go with TortoiseSVN? And lastly... do you recommend I hunker down tonight and start reading the version control documentation for this stuff so I can become acclimated to the features and how to use it? I'd like to put this to good use for keeping things organized on my end (as a sole, single developer).
Thanks so much again.
Now, I'm looking at Subversion and I'm guessing a windows spin-off called TortoiseSVN... should I just go with TortoiseSVN? And lastly... do you recommend I hunker down tonight and start reading the version control documentation for this stuff so I can become acclimated to the features and how to use it? I'd like to put this to good use for keeping things organized on my end (as a sole, single developer).
Thanks so much again.
- feyd
- Neighborhood Spidermoddy
- Posts: 31559
- Joined: Mon Mar 29, 2004 3:24 pm
- Location: Bothell, Washington, USA
I highly recommend reading the bulk of the book, if not all of it. I also recommend knowing the command line interface over the GUI. While I have no major problem with using the GUI interface, I think it's best to know what's actually going on behind the curtain.
Tortoise is simply an interface, not the server. Tigris has builds of a Windows server on their site however.
Tortoise is simply an interface, not the server. Tigris has builds of a Windows server on their site however.
- seodevhead
- Forum Regular
- Posts: 705
- Joined: Sat Oct 08, 2005 8:18 pm
- Location: Windermere, FL
feyd... so it sounds like you would rather have me just go with subversion and work it by command prompt, correct? I'll take your recommendations if you don't mind.. I want to start off on the right foot and don't mind having some of your experience rub off on me! 
Now that I have apache, mysql and php installed on my windows machine.. it sounds like I can now install subversion on it? I don't need to get a remote server specifically for subversion for subversion to work, correct?
Now that I have apache, mysql and php installed on my windows machine.. it sounds like I can now install subversion on it? I don't need to get a remote server specifically for subversion for subversion to work, correct?
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
TortoiseSVN bundles the Windows subversion binaries so its server ready. Just create a new directory, right click, "TortoiseSVN" (TSVN works from the mouse dropdown), and "Create repository here...".
Knowing the command line kind of forces you into seeing the workflow without the GUI getting in the way.
Knowing the command line kind of forces you into seeing the workflow without the GUI getting in the way.