Subversion is a pretty easy concept. The latest copy of the source is on the server. each developer has his "own" copy of the code.
Every day, I update my code (svn update). We get emails after someone commits, and we generally know who's working on what before hand. If I see a commit on something I need to touch, i make sure they are done, do an update, make my changes and so on.
It's a huge time & life saver. YOu can keep track of who does what and when, and if you make a mistake, it's only a few minutes and you can revert the changes.
Eric Coleman
On Feb 25, 2006, at 2:16 AM, Trevor Harmon wrote:
On Feb 24, 2006, at 10:17 PM, Ned Baldessin wrote:
This article is interesting, but too vague : http://www.sitepoint.com/blogs/2006/02/07/using-svn-for-web- development/
I disagree with the author's claim that it's necessary for all developers to work on the same server. It's not hard to set up Apache locally with the same configuration as everyone else. I don't think you have to jump through all the hoops that are recommended in the article.
How do you guys handle SVN, and how have you integrated it in TM ?
We put our repo on a centralized machine. Team members would check in changes, and the manager would periodically update from HEAD and to see how things are progressing and run some tests on the deployment server. It worked fine; I don't see anything "tricky" about using SVN for web development.
My latest idea: using the auto-commit on save when you mount a webdav repository as a drive.
I assume you're not talking about a shared repository, where auto- commit is really not a good idea. You should only commit stable changes -- manually -- and include a description of what the change is in case it breaks something.
Trevor
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate