SVN代码管理

当你每天commit 、chenkin、checkout code成为习惯时，也许不会太在意为何这样做!
当你熟悉SVN代码管理中简单的提交、解决冲突时，是否已经知道working copy 与working base
进行代码比较的时候，是否意识到SVN代码管理的整个架构呢？这篇文章真的不能给你带来什么技术的价值，
但至少能给你带来一些思考，学会一种解决问题的方式，而不是看到问题就Baidu搜索，
不否认搜索为我们带来的巨大便捷，但结果里面有太多我们不需要甚至误导我们的东西。既然选择技术
研发行业，选择平和的心态深入踏实学习很重要。哈哈，说的有点沉重，归根到底，我们应该充分利用帮助文档，

来解决我们的problem，这才是彻底解决你疑惑的良师益友；Just do it，相信不久的将来，你会对代码管理的架构了如指掌；

下面摘录一段SVN help 文档中关于working copy的说明，对于working copy顿时茅塞顿开。本打算翻译一把，但还是感觉原汁原味比较爽吧！

About Subversion working copy 

A Subversion working copy is an ordinary directory tree on your local system, containing a collection of files. You can edit these files however you wish, and if they're source code files, you can compile your program from them in the usual way. Your working copy is your own private work area: Subversion will never incorporate other people's changes, nor make your own changes available to others, until you explicitly tell it to do so.

After you've made some changes to the files in your working copy and verified that they work properly, Subversion provides you with commands topublish your changes to the other people working with you on your project (by writing to the repository). If other people publish their own changes, Subversion provides you with commands to merge those changes into your working directory (by reading from the repository).

A working copy also contains some extra files, created and maintained by Subversion, to help it carry out these commands. In particular, each directory in your working copy contains a subdirectory named.svn, also known as the working copy administrative directory. The files in each administrative directory help Subversion recognize which files contain unpublished changes, and which files are out-of-date with respect to others' work.

A typical Subversion repository often holds the files (or source code) for several projects; usually, each project is a subdirectory in the repository's filesystem tree. In this arrangement, a user's working copy will usually correspond to a particular subtree of the repository.

For example, suppose you have a repository that contains two software projects。

                                                                    The Repository's Filesystem

                                                          

In other words, the repository's root directory has two subdirectories:paint andcalc.

To get a working copy, you must check out some subtree of the repository. (The term check out may sound like it has something to do with locking or reserving resources, but it doesn't; it simply creates a private copy of the project for you.)

Suppose you make changes to button.c. Since the .svn directory remembers the file's modification date and original contents, Subversion can tell that you've changed the file. However, Subversion does not make your changes public until you explicitly tell it to. The act of publishing your changes is more commonly known as committing (or checking in) changes to the repository.

To publish your changes to others, you can use Subversion'scommit command.

Now your changes to button.c have been committed to the repository; if another user checks out a working copy of/calc, they will see your changes in the latest version of the file.

Suppose you have a collaborator, Sally, who checked out a working copy of/calc at the same time you did. When you commit your change tobutton.c, Sally's working copy is left unchanged; Subversion only modifies working copies at the user's request.

To bring her project up to date, Sally can ask Subversion toupdate her working copy, by using the Subversionupdate command. This will incorporate your changes into her working copy, as well as any others that have been committed since she checked it out.

Note that Sally didn't need to specify which files to update; Subversion uses the information in the.svn directory, and further information in the repository, to decide which files need to be brought up to date. 

In other words, the repository's root directory has two subdirectories:paint andcalc.

To get a working copy, you must check out some subtree of the repository. (The term check out may sound like it has something to do with locking or reserving resources, but it doesn't; it simply creates a private copy of the project for you.)

Suppose you make changes to button.c. Since the .svn directory remembers the file's modification date and original contents, Subversion can tell that you've changed the file. However, Subversion does not make your changes public until you explicitly tell it to. The act of publishing your changes is more commonly known as committing (or checking in) changes to the repository.

To publish your changes to others, you can use Subversion'scommit command.

Now your changes to button.c have been committed to the repository; if another user checks out a working copy of/calc, they will see your changes in the latest version of the file.

Suppose you have a collaborator, Sally, who checked out a working copy of/calc at the same time you did. When you commit your change tobutton.c, Sally's working copy is left unchanged; Subversion only modifies working copies at the user's request.

To bring her project up to date, Sally can ask Subversion toupdate her working copy, by using the Subversionupdate command. This will incorporate your changes into her working copy, as well as any others that have been committed since she checked it out.

Note that Sally didn't need to specify which files to update; Subversion uses the information in the.svn directory, and further information in the repository, to decide which files need to be brought up to date.