Versioning: Some of the usage feelings of SVN and git __svn

background:

Originally in the school to follow the mentor to do the project, has been using version management, mainly to record the changes in the project, the project members of the communication and communication. The server used is visual SVN, the client is TortoiseSVN, and the commonly used TORTOISESVN directives are limited to SVN update and SVN Commit, which are updated from the servers to look for changes from other students, The latter is used to submit its own modifications to the server, allowing the team to share the modifications. Because there are fewer members in the project team, the main code modification was done by me alone, so TortoiseSVN became a tool to record my changes to the local code process. In fact, this and I usually write the log (Word format), the code to add comments (comments in general will be the reason for change, modified, modified time, notes) the habit of having some redundancy.

Then enter the workplace, contact with more and more projects, more and more developers, slowly began to understand the other features of TORTOISESVN. For example, view the file change log show log, rollback committed modification operations revert, create branch Branch/tag, create a patch created patch, and so on. In the gradual familiarity and use of the situation, gradually feel that tortoisesvn seems to lack a bit of what function. For example, the following scenarios occur frequently: I copy my own code from the project SVN server to my laptop, and then I start to modify my own module (like debugging locally) on a project plan, but suddenly I get instructions from my supervisor and have an urgent bug to deal with. At this point I can only create a patch file (the Create patch) and then roll back the current changes to the initial state (that is, the version I copied from the SVN server), so I can start to modify the urgent bugs. Wait for the patch to complete, then apply the previous patch file back. In this I will also do the corresponding work record (Word document), in which I will record the initial changes in the module of the relevant steps and details, record the bug patch process, and then record the changes in the module. So, combined with TortoiseSVN's submission log and my Word working document, I can pinpoint any moment in my development--easy to follow up and continue, as shown in the following illustration: If the time granularity for each TORTOISESVN submission is as shown in the yellow arrow, So in the middle of the red change I can only see in my word log, but Word is recorded in the mind after all, the specific code files I can only manually copy to the word in the record of the corresponding location, or create patch files saved to the development location, If the time granularity of the TORTOISESVN submission is shown by the arrow in the way, then this is almost repetitive with the word log, and can be used for arbitrary location modification purposes, but it should be noted that in team development, such frequent tortoisesvn submissions are absolutely impossible, One is that the SVN server requires complete functionality changes to be completed before submission, but so frequent submission will increase the burden on the server, but also make their own incomplete code modules affect the entire project's functionality.

See here, you are not feel good complex, good trouble, but for the code farmers, good records and comments are necessary, so that you can better be responsible for their own code. I've been doing this for years and I'm used to it, until one day when I touch git, I realize there's a so-called distributed version management tool that records my local changes. It really makes me happy.

Here's how to use git to manage local code modifications. git manages local code modifications: 1 The difference between git and svn:

The analysis and discussion of both are already all over the major forums, post bar, here I do not evaluate the advantages of the two are inferior. From my own actual code development work, from the point of view of improving the efficiency of my own code development, I think of the two. As stated in the background, SVN has been in use for many years, simply that there is a server that will store your modifications to the code, and the modification here must be a commit (commit) to the server. The granularity of two of submissions is entirely up to the developer, and if you are simply using SVN to manage your own code development record, you can easily submit your own complete development process with expectations (this is a way that is not allowed in team work). SVN's structure is divided into version libraries and working copies, a repository is a "database" on the server that records your submissions every time, including changes to files within the scope of all repository controls; The working copy is your own code engineering in this machine, which is a copy of the Code engineering SVN stores the version library and working copy in a different location. The specific schematic below (the direct embodiment of their own ideas, may not necessarily fully conform to SVN's work process, but the effect is correct, easy to understand):

As you can see from the diagram above, the basic process of SVN version management is that the server saves the changes you make to the project each time, and of course the first time you submit it is your initial project document. So from the directory structure of the SVN server above, we do not see directly the project files we submitted, while the use of TORTOISESVN (local servers) and VISUALSVN (remote server) Repo-browse can see our specific project files, as shown below. So where is the file we submitted? Intuitive guesses should be some of the files in the DB directory, because the size of the file changes as the number of submissions increases. Search for relevant information, found the following answer:

"SVN has two ways of storing: BDB and Fsfs, at present, the most is the FSFS way, this way, is generally stored in the \db\revs folder, which has a bunch of files named after the version number, such as: 0, 1, 2, 3, 4 ..., that is our engineering documents. SVN first compressed the 0 version of the state into 1 files, and then each version update for the change of the part of a compressed file, each time is to add an incremental package, and finally on the server can see the file name from 0 to the final version of a series of files.

"The SVN server side is not simply storing the uploaded files one at a time, and the SVN server-side default FSFS format is to store each commit's content incrementally, with each incremental package saved into 1 files, which includes all the data for this commit." That means you can't find a file that you uploaded on the server side of the Repository folder.

So we know the structure of the SVN server. As for the client, there is no difficulty. It is through the network protocol to download the server version of the library to the local, stored in the. SVN directory, in addition to their own engineering files (if you are from the remote SVN server to download the project, it is someone else's engineering file). SVN records the status of your server engineering files from the time you download the SVN server, and the next time you submit, you will be communicating with the SVN server to see how the server and your local ends are modified.

From this we can see that in order to record local changes, we must communicate with the SVN server, can not simply save the local changes. This is the main purpose of my quest for git. Baidu Wikipedia's description of Git is: "Git is an open source distributed version control system for efficient, high-speed processing from very small to very large project version management." The biggest difference between a distributed and a centralized type is that developers can submit them locally. Each developer machine has a database of servers. "--anyway, that's a word, git can do the local change record I want above." 2 git admin Local code modification

In the first step, Git's version library and working copy are in the same directory, called. Git. After you install Git, you can right-click in any directory and select Git Init here to create a git version library, the. git folder. (Remember: This is our locally built version of the library, there is no server hair relationship Ah, ^_^. ）

The second step is to copy the local project we need to manage directly to the. git directory. Then we want to open the project like normal development to do, until I want to save the change status, we can go to step three.

The third step, the right key in the Engineering folder, select Git Gui, will pop up the management window, here will show us the changes, in the red box is listed in our modified files, Orange Box can see the changes. The green box shows the modified buffer, and by selecting the specified file into the green buffer in the red box, we can click "Submit" with the yellow button, and this time we have submitted a record of our changes to the local file.

The fourth step, in the Engineering folder right button, select Git History, we can see the local change record.

At this point we can easily implement a record of the local code modification, and throughout this process, there is no server at all. This is the biggest difference from SVN.

Today it is recorded here, tomorrow will be a detailed description of the scene in the background, give a git solution.

(To be continued ...) )

Author: zssure@163.com

Time: 2014-09-06