Subversion question

Is that non versioned file already in your repository?

I'm not too sure what you mean. Do you mean that in your dev home you have a file that is of the same name and path as a file that you want to keep separate from the repository? And then whenever you try and do an update you have to stop this file being overwritten? If so, then why is that file the same name and location as the one in the repository and why do you want to keep it outside version control?

A better idea of the directory structure and the commands you are using would help us help you with the problem.

Jon

EDIT: 99% of the time when Subversion complains to me it means I've done something silly.

when u delete a file it is best to do it via right click and via tortiose. Anyway if you use the repo browser you should be able to delete stuff.

If you have everything checked in try forcing a revert to the current version rather then an update, that might do it. Make sure it is reverting to the current version though!

I guess I didn't explain the situation very well. Here are the steps I took:

1. Import my project folder to the repository
2. Go to another machine and check out the project
3. Modify the project
4. Commit all changes
5. Return to my original machine and choose Update to obtain the latest changes

I'm simulating multiple users here working on the same codebase on different machines. The users do not edit the same files, so no conflict occurs. What I want is to be able to pull in the latest changes for the codebase (say, every morning).

Am I thinking about this incorrectly? When I choose "Update", I would imagine that Subversion would go out and get all the files in the repository that have changed and update my working copy. I get an error message about a non-versioned copy of a file already existing on my system. Well, I didn't choose to have that file non-versioned and of course it's there: it's my copy as of the previous day!

Any ideas?

You're doing something wrong.

What are the steps you would take to add a project to the repository and then update your working copy later on?

Just a wild guess: Do you have any temporary/generated file in your repository (famous examples are the .suo/.opt Files from Visual Studio)

Greets
Julien

Quote:

Original post by Julien Koenen Just a wild guess: Do you have any temporary/generated file in your repository (famous examples are the .suo/.opt Files from Visual Studio) Greets Julien

This happens all the time in projects with more than a few people, when people checkout a repository and then accidentally commit the binaries. Probably on machine 2 you added the .obj files, (or .o on *nix) and since they already existed on machine 1 subversion starts whining.

Quote:

Original post by DaWanderer 1. Import my project folder to the repository 2. Go to another machine and check out the project 3. Modify the project 4. Commit all changes 5. Return to my original machine and choose Update to obtain the latest changes

That's not how it's done (even though it feels more natural to many people). Instead, do this once:

0.a) Import my project folder to the repository
0.b) Delete original folder (or rename and delete later or whatever)

then, do the following as often as you like:

2. Go to _any_ machine(possibly the one you used to import the original files!) and check out the project (or update, if you already checked out earlier)
3. Modify the project
4. Commit all changes

The important thing to note is: The initial copy you used to import is not a checked out copy. It cannot be used to work with subversion. You need to check out your own copy. (Even though you already have all the files)

On the temporary files thing you can tell SVN to ignore directories and files.



In this working copy dir you can see the folder bin and file MANIFEST.MF, these are both generated at compile and aren't something you really want to store in the repository so right click and choose Add to ignore... in TortoiseSVN.

Thanks a lot for the responses, everyone. I was checking in everything, including the suo file from VS.NET. I wasn't aware of the ignore feature, so I'll just do that with all the temporary files.