views:

188

answers:

4

I'm learning to work with SVN using Visual Studio.NET. Everything works fine and all but I couldn't figure out something:

I have my original source code at c:\source

I created a repository at c:\repo (svn://localhost)

I added my solution to repository using VS.NET at svn://localhost/MyProject/trunk

I checked out a working copy from repository/trunk to c:\working copy

I made a few changes to myfile.cs of this working copy and committed without any errors. I updated to latest, checked out again etc. and it's all good.

But, I checked the same file at c:\source\myfile.cs from Windows Explorer and it's the old version. No modifications made to it at all. I thought committing work would change the original trunk version? Am I missing something here? Or am I understanding source code management all wrong?

+4  A: 

Your working copy is, of course, C:\working copy; any changes you make to the working copy will be reflected in those files. When you commit, you are committing to the repo at C:\repo\<repo>, so when you check out from that repo, you'll also see the changes.

The original source files in C:\source, however, are not touched, since it's neither your working copy nor the repo itself.

mipadi
True, true. I was typing up the same thing but you beat me to it :-)
sjobe
+2  A: 

Actually, your C:\source doesn't have anything to do anymore with the source itself. It's not connected to anything (is not a working folder).

You have your repository at C:\repo, and the changes remain there when you perform a commit.

You will download the changes when you perform a UPDATE on a working folder (IE, C:\working copy)

Andrea
A: 

Alright the original source is useless once you add it to repository.

So what do you do when you need to merge all working copies of several different people and make a final build? You make a custom makefile on the server and call it? Or use an automated build system?

Armagan
When using Subversion, everyone (all developers) should be pushing into the same repo; then you just check out a copy (with all changes pushed/merged in) and build.
mipadi
+2  A: 

To answer your follow-up question: You want to compile the current repository trunk, not whatever would result from automatically merging everybody's current working copy. The odds of that even producing code that compiles are pretty low.

When you finish a good change and test it with a local build, commit it to SVN. Whatever is in the repository is the authoritative code and your build system should be compiling that.

jtb