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 have 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.
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.