I missed portions of this thread, but I've been SVN-dependent for the last couple of yrs having switched from CVS (...and prior to that, RCS). and I rely on the #1 method you suggested here. This method has saved my *ss a gazimbillion times.
What #1 allows is... is to make the local repo your gigantic undo stack --- especially invauable if you're taking some work with you on the road, possibly without net access, and/or if you'll be checking out assets for days at a time, etc..... And then once you're ready to 'publish' you can commit to a separate repo for other users to checkout from.
OTOH, the method #2 might work better if everyone on your team is known to be 'connected' fulltime and makes frequent check i/o's. Depends on the type of work you do, I'm sure. YMMV.
BTW, to another poster recommending no commits until something is verified to work ------ That's asking for trouble. Even if unverified, you should commit regularly... just make sure to log useful information. Your repo will not inflate much for minute changes. Again, YMMV.
#1 is not a streamlined process, however, because you have to maintain multiple repos. This gets confusing sometimes. So what I do is, everything I edit in Txmt accesses the local repo, and using another SVN program (svnX and SVN Finder Plugin on Mac, and Tortoise and Ankh on PC) I check i/o to another 'public' repo.
FWIW, -Shin
p.s. Here's a feature req for the SVN plugin.. Maybe offer a preference-able item for 'default' comments, maybe stick some fields that can be typed over. And 'use last log' if a commit fails for some reason. Ankh for Visual Studio on PC does this, and it's quite a time-saver.
On 3/30/07, Charilaos Skiadas skiadas@hanover.edu wrote:
Before we continue down this road, let's be clear about what Rob is suggesting, because I was also mislead in my original responses by not reading his post carefully. Rob is not suggesting not to have version control. In fact, he already has it in all his servers. What he is saying is, what are the advantages of 1 over 2, where 1 and 2 are:
- Having two checkouts of the repository, one local and one on the
web server. Then making changes to the local version, committing and then updating the server side. 2) Having only a checkout of the repository on the web server, and remotely editing that checkout. Then testing, and only committing the changes if things work out. So he can still revert his changes.
So I think some of our points remain valid, but let's be clear about the issue. The issue is not version control or no version control, the issue is local checkout and not directly editing on the web server, versus direct editing on the web server.
Haris Skiadas Department of Mathematics and Computer Science Hanover College