Here are common problems that are prone to ease in the process of using version control, these issues come from physical work. However, this list is not necessarily comprehensive, and for specific individuals, the situation is not the same. There may be a list similar to this list of developers who use version-controlled developers, and perhaps this list will be expanded and continuously improved. Item 1. The logical structure of the project is confusing ("Project" here is the term in version control, see A.1) This is an easy problem in implementing version control, especially for project development (non-speech here) ). There are many reasons, such as: In the beginning, the demand is not clear, causing the software itself structure to confuse, so that the logical structure of the software is often changed. Another example: a team, everyone cares about the module that you are responsible, each of which develops a logical structure suitable for you, causing the final project structure being a hodgepodge (a plurality of structures). Over time, the software management will cause confusion, increase maintenance burden, but reduce efficiency. Structure, some directories may be "dead angle", never use; some directories may be repeated, resulting in redundancy; some directory may be in the same, each of them affects each other. From start to the logical structure of the project, it is necessary to persist. Item 2. Multiple people modify the same document once there is such a situation, it is very likely that someone's hard work will be destroyed by others. Its solution is: In general, ensure that only one member is modified to a particular file at any time, which prevents files from being updated by other members. In order to adapt to many people to modify the same document, version control administrators can also change this default settings to allow a single file to be checked out in the same way, and still prohibit the coverage of others. Item 3. The local version and server version may sometimes encounter such a situation, and the developer updates some of the content when updating local version from the server, causing local compilation to pass. It should be noted that the consistency of the local version and server version is always, which is aware of awareness because the server version is actually effective. Multiple programmers must also be careful not to waste time in order to solve the same problem. Implementation of a function, due to the inconsistency of local and servers, leading to everyone to repeat. All content of server-side data should be backed up, including all subfolders, regular backups, is an absolutely important job. Item 4. User rights confusion for all developers and their respective modules, based on actual conditions, which people have only readable permissions on which directory is read, which people have read and write permissions. All people should not appear are extreme situations such as administrators. Item 5. The read-only tag of manually modified files To prevent you from modifying the files that have not been checked, the version control management tool specifies and marked as read-only files. When you check out a file, the read-only tag is deleted. A frequent adverse habit is that in order to make an information, try to modify the file when there is no signapping file, and when the discovery file cannot be saved, it is manually modified its read-only tag. This is a "source" that will lead to inconsistency, and the effective content is covered. Item 6. No specified work directory or multiple work catalog Each developer must have a unique working directory, which cannot be shared with any other developer ("Work Catalog" is the term in version control, see A. 2).
