Approach to using SVN and TortoiseSVN

Question

It seems that the best approach to using SVN and TortoiseSVN is for each developer to have their own copy of the project files ?

i.e. Do not use a common network drive area to hold copy of project files (with > 1 person updating files in area and then each trying to do SVN commit/updates..)

Can people please confirm this approach of each developer with own copy of project files out of SVN ?

I have also spotted these forum questions and replies which I believe confirms this approach of each developer holding their own copy of SVN project files:

How do you setup a shared Working Copy in Subversion

Using SVN alone or in small workgroups - workflow approach?

When we were using a common network area for the project files outside of SVN, I managed to get some interesting errors/situations !

For example:

Error Commit failed (details follow):

Error Directory ... is out of date

Error File not found: transaction '2134-1sc', path ...

Error You have to update your working copy first.

Error Commit failed (details follow):

Error Aborting commit: '.....'

Error Folder .... remains in conflict

Error sqllike[S10]: disk I/O error

Answer 1

I confess that used to be my approach when I started coding in the early 2000s:

• A shared file server that would host everything that had to be backed up.
• A shared application server what provided all the services: web server, database server, etc.

Programmers would edit files right on the file server and would test them through the application server (which also access the same files).

That was before my company adopted any version control solution so I guess it kind of made sense at the time because it was a way to solve collaborative work on the same project. But things have changed a lot in two decades:

• Version control no only makes this unnecessary but it also fails to work properly. SVN in particular performs file system intensive tasks, esp. for certain operations like svn update, that require exclusive access to files and current working copy format uses a binary relational database file that requires an exclusive lock (that's what your error messages highlight).

• Modern IDEs and programming tools are often built around the expectation of lightning fast disk access and lag terribly with network drives (a fast wired LAN can't compete with a local SSD and in my experience most local networks perform badly).

• Open source stacks have become the norm and even commercial solutions offer free access for development purposes so it's trivial to set up local environments.

• Shared set ups often lead to an unmaintainable mess of hacks and makes it impossible to run the project anywhere else because nobody currently in the company knows how everything works. When you need to install the application from scratch regularly installation steps tend to be better documented and installation issues tend to get addressed properly rather than workarounded.

• Being completely free to play with your code is a boost for quality and innovation and shared environments interfere with that.

So my advice is that you attempt to make each development environment as self-contained and automated as possible, and that certainly includes local Subversion working copies. But I'd also ensure that everyone in the team is using version control as it's meant to be used—you'd be surprised to learn how much people considers Subversion a backup system or a Dropbox clone, so they hardly benefit from it.

The official Version Control with Subversion book is still a good starting point. Unfortunately it's becoming obsolete and newer features are barely documented. I suspect the svn team is becoming understaffed as Subversion is being replaced by more popular systems (namely git).