Tortoise svn multiple users project file corrupted

[D60]

Hi!

I've been working in a team, and we've decided to start to use Tortoise svn in our projects. I made a working copy, and all of my vis, project files and so on are oraginzed in files, so I made a commit, all of these are committed. My college made a chekout, made some modification, save the project and committed.

I've updated my project with the last revision (his last commit) the project file was corrupted, and it was unable to open.

I've realized that, the project file was under version control, and his last version have been downloaded.

Could you give me some advise, suggestion how do I manage and organize files in order avoid this corruption/error?

I'm very new in SVN as it seems :), so my next question is, how to do that:

I'm developing and committing, my college do the same. Is there any way to merge these different development to one?

Thank you very much!!!!

[jcarmody]

My first (and only) thought was to ask if you're using an SVN server or just a file on a shared drive.  I recall reading that multi-user applications must use an SVN server or risk horrible consequences.

[jcarmody]

---

@jcarmody wrote:

[...] I recall reading that multi-user applications must use an SVN server or risk horrible consequences.

---

 I found the warning, here:

---

Accessing a Repository on a Network Share

Although in theory it is possible to put a FSFS repository on a network share and have multiple users access it using file:// protocol, this is most definitely not recommended. In fact we would strongly discourage it, and do not support such use.

Firstly you are giving every user direct write access to the repository, so any user could accidentally delete the entire repository or make it unusable in some other way.

Secondly not all network file sharing protocols support the locking that Subversion requires, so you may find your repository gets corrupted. It may not happen straight away, but one day two users will try to access the repository at the same time.

Thirdly the file permissions have to be set just so. You may just about get away with it on a native Windows share, but SAMBA is particularly difficult.

file:// access is intended for local, single-user access only, particularly testing and debugging. When you want to share the repository you really need to set up a proper server, and it is not nearly as difficult as you might think. Read the section called “Accessing the Repository” for guidelines on choosing and setting up a server.

---

[tst]

Recent versions of TSVN are configured to automatically merge changes if there are conflicts when you update. The .lvproj file is mostly simply XML, but doing a simple ASCII merge on it might lead to corruption, and I'm guessing this is what happens here.

I would start by looking up how to disable the auto-merge (if memory serves, it's not as simple as checking a box) and then I would suggest you go read some material on working with LV and Subversion. There's stuff both in the large apps group on this site and in the LAVA forums.