New to SVN, should i keep a project's local copy?

I am very new to SVN, my project usually are .NET winforms project, in the past, there is a share folder on network drive , and being a "current build" folder.

my team, 3 members, all of us have a local copy on my own windows. The problems is come out, it possible programmer A & programmer B modify a file on same time and A overwrite B's files etc.

My boss ask me build a SVN to prevent the the problem above.

I 开发者_如何学JAVAhave search on SOF and understanding the concept of SVN, however, Somebody said it must be checkout the source from /branch folder ,after finish, check-in back to /branch folder and merge to /trunk.

It make me come out some question: Assume my project contains 3 files :

• Cart.cs
• Product.cs
• Customer.cs

And the SVN repository structure :

• /trunk : Cart.cs / Product.cs / Customer.cs

--

Today, i want to modify Cart.cs, i copy Cart.cs to /branch and place create a new folder "1.0.1" and checkout to my local and open on VS2010, but the Cart.cs inherits the Product.cs, so it make some "missing reference" error on my VS.

So, the right way is copy all files to /branch/1.0.1 and checkout to local or just keep a local copy and overwrite the files from /branch to get the compilation correct?

Thanks you.

You do seem to be confused on the fundamental concepts of SVN. I highly recommend you read the first few chapters of this book, especially Chapter 2 and the part on the basic work cycle.
Subversion Red Bean Book

What you should be doing to get the most out of SVN is something like this.

You create a repository and store any startup files or whatnot in there, making a special folder for you project, and then folders within that, i.e.

/myProject
+ trunk
+ branches
+ tags
+ sandbox

from there, all your work should be done in the trunk. Everyone should checkout the project from the trunk, and work on their local (working) copies individually, ideally on one task/issue at a time. After you have fixed a big or implemented a new feature, you synchronize your work with the repository, at which point if conflicts arise, you should resolve them. SVN will not let you check in conflicted files. You have to either postpone, overwrite, or merge your work with the trunk. If you need to communicate with another developer at this point, you should. Once you have resolved all your conflicts and tested everything out with your working copy, you can commit your code and publish your changes back into the trunk, and then update.

Branches are used when you need to diverge from the trunk to implement a specific feature without committing to the trunk. After a few days you should merge the trunk into your branch, and then eventually you will need to merge the branch into the trunk anyway.

If you're wanting to just get started with a very simple set-up, you could create a branch in your SVN repository with a folder/branch called "Trunk".

Each developer can then check-out that repository to a folder local to their machines. When they make changes, they commit these changes to the "Trunk" repository branch.

When you know someone else has made changes, you do an "Update" on your local copy to pull those changes.

Lastly, when you do some release, or hit some milestone, you can "Tag" that release with a name such as "Release 1.0.1" (where a tag is really another branch that contains the code for that given instance of time, you won't keep working on that branch, but leave it as stable).