How to cope with changes-design of subversion and perforce

First, both are currently widely used source code management tools. P4 is a commercial software, so it is mainly used inside the company. Its functions are basically very good and powerful. SVN should not be said. It is basically used by open-source projects nowadays, and open source.

This is not an article about the two tools. I want to talk about how the two tools handle version changes.

In the recently published "The beauty of code", Karl Fogel specifically introduced the incremental Editor (PS) in SVN. the translation of some chapters in this book is too amateur, such as dynamic programming (Dynamic Programming is probably known by freshman students) and functional programming (functional programming is very popular recently) interface (in combination with the context, it is obvious that the interface function is called). It is really doubtful about the translator's level. Later, I paid special attention to the observation and found that this is really the case. For example, someone adds a new file F. cpp to the server and deletes it. After that, if you sync, you can probably observe the following log:

......

Add-F. cpp

......

Delete-F. cpp

......

That is to say, all changes recorded in SVN are recorded, or even more directly, each commit operation. Then, these operations are organized into several group Operation trees on the server. When sending a sync request from the client, the server needs to access the records in a certain period of time in sequence, and then perform corresponding operations (such as adding, deleting, or updating files ). In this way, even if the two operations can be offset, for example, if the same file is created and deleted first, the two operations will be simply executed, the result of the two operations is actually no result :)

However, if you use P4. CPP operations, such as sync to head version, you will not see F. any operations on CPP, because this file does not exist in the repository at this time, so there is no need to notify the client. Because I have not read the relevant documentation, I am not sure how the P4 server manages versions. However, in this case, the result observed in the P4 log seems to be directly traversing the repository file tree, rather than processing each submission in sequence, therefore, it is suggested that the internal use of P4 is more likely to be based on the file revision management method. Of course, this is purely a guess. Maybe someone else's bottom layer still uses incremental records like SVN, but it's just that some peripheral optimizations or just a blind eye. In addition, when sync to a change list in P4 was not carefully observed, it may be the same as Svn in this case.

However, in terms of the two methods (assuming that I guess the P4 design is correct), I personally think that the incremental record of SVN is more like operation-oriented, but actually there are several versions of Version Management centimeter operations, in this way, the internal design and implementation are easier. Once the underlying processing method is determined, the internal development work can be greatly simplified; the P4 design tends to be more data-oriented (here it is a code file), so it may be more complicated internally, and the maintenance and upgrade estimation is not that easy, in turn, the advantage is that it is easy to perform special optimization processing on the basis of data. Speaking of this, let's go back and think about the commercial software and open-source products introduced at the beginning of this article. Do you think of anything else? ^_^

 

In fact, recording and managing changes is a common problem in software design. The core of Undo/Redo and transaction technologies is to deal with changes. In the operating system, Memory Page Management, database transactions, synchronization in online games, and even parallel processing methods in some programming languages, you can see the application of various change processing technologies.