views:

52

answers:

2

I am having problems with tortoiseSVN and Subversion. Process is as follows:

  1. I create a new repository on computer A.
  2. I checkout the repository to a working copy on computer B (we use a peer to peer network, both PCs with Windows Vista).
  3. I copy files and directories for an ASP.NET website into the working copy.
  4. I add the files, then commit them. So far, so good.
  5. I edit a file in the working copy on PC B.
  6. I commit the file and then the problems begin:
  7. First, tortoiseSVN fails to commit because it cannot delete a file in the repository.
  8. A second attempt to commit and tortoiseSVN says that the file is out of date.
  9. I run a tortoiseSVN update on PC B. Succeeds, with no changes.
  10. I try to run the commit on PC B and get same file out of date error.

It seems to me as follows:

The initial commit has partially succeeded, despite the error. As a result, the file is out of date when I try to commit a second time.

However, there is clearly something else wrong: checking out a new working copy, this time on PC A, shows that the changes to the file WERE committed. I can then make changes and commit them without problems. Note that the Repository is on PC A. So working copies on PC A seem to work fine.

The peer to peer network also appears to be working fine.

So I really don't know what to do. We need two people working on this website so we need version control.

Any help appreciated. I am now at the pie eyed stage where I really don't know what to try next.

+1  A: 

This sounds like a tree conflict, which are well described on Resolving Conflicts.

zellus
Zellus, thanks will read that in more detail in the morning, as there are suggestions that are worth following up on. Regarding my problem, the repository is new, so I can't see how it can have a tree conflict. There must be another issue, but can't see how. Maybe the folders that I added, that used to be part of another repository, have some .svn folder from an old repository lurking in there?
awrigley
@awrigley: Lurking *.svn* folders seem to be a probable reason. *svn export* can be used for workspaces as well, in order to omit *.svn* folders.
zellus
@zellus: I think actually I had exported from the old repository, so it shouldn't be that. Anyway, tomorrow I will export again and recreate the repository (yet again) and see what happens. Thanks. (still not sure of reason so as to accept, but you're top of the list so far...).
awrigley
@awrigley: I'm happy to help anyway!
zellus
+1  A: 

If you are using the file:// protocol, you should note that TortoiseSVN doesn't support it:

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.

One reason that TortoiseSVN doesn't want to support this scenario is that if one person upgrades their TortoiseSVN and someone they are working with doesn't, it can cause all kinds of problems.

Dingo
@Dingo: We are using urls, not file://
awrigley
You state in a comment above that the repository path is \\PCNAME\Repositories. That's a UNC, not a URL. You are using the file:// protocol, but probably don't realize it because Tortoise is taking care of the details for you.
Dingo