标签：svn 管理 架构 研发 subversion
当你每天commit 、chenkin、checkout code成为习惯时，也许不会太在意为何这样做!来解决我们的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。
In other words, the repository‘s root directory has two subdirectories:paint and
calc.
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 and
calc.
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.
标签：svn 管理 架构 研发 subversion
原文地址：http://blog.csdn.net/gggg_ggg/article/details/45690323
