Version Control, git, and Domino

Version Control

When talking about version control, programmers will think of various source code control tools used in their work, such as subversion, git, mercurial ...... In fact, many files other than the source code also need version control. The idea of a version and its management have always existed in the era of printing and handwriting before the emergence of computers. The version is a symbol of the growth and evolution of works. In the era of handwriting and printing, text works only record its modification and growth. By the advent of computers and electronic files, the file size, content complexity, and version update speed are all unprecedentedly increased. In addition to recording different versions, version control has been put forward with many new functional requirements: restoring to any previous version, comparing the differences between the two versions, creating multiple branch versions, and merging different versions. Especially for programmers, these functions are of great benefit to debugging errors, Understanding code evolution, collaboration among multiple people, and development for multiple users and purposes.

Git

Like other software tools, Version Control Systems (VCS) (Version Control System) or RVs (Revision Control System) evolve along with actual needs. At first, all the data of the managed files was stored in the local repository (repository), and then evolved into the client server mode. The repository was saved on the server, the version control system changes from a standalone version to a multi-person online version. The only drawback of this architecture is that only the server maintains the complete historical data of files, and each client only has the current version. In this way, operations such as switching, comparing, and merging among multiple versions need to be connected to the server for Data Query and transmission. In addition, once the database on the server is damaged, all historical accumulation will be irrecoverable. Distributed version control system (DVCs) was born to better adapt to the environment of free development by multiple people. Just as the distributed database system has multiple copies of a single database on different nodes, each DVCs User Machine stores a complete repository. In a standalone state without network connection, programmers can also use all version control functions. When the network is connected, they can synchronize with the storage libraries on the server.

Git is an excellent distributed version control tool. It was originally written for Linux programmers to develop systems and has become the most popular version control tool, especially in the Open Source Field. GitHub is the largest source code hosting website. Compared with the predecessor, git has some special ideas. For example, each version saves a complete file instead of a file difference (if a file has not changed, contains references to the previous version file ). There are many excellent introductions and teaching materials on the Internet, such as the GIT official website document http://www.git-scm.com/docand the GIT concepts simplified, which is quite understandable.

Domino

In the notes discussion series, I repeatedly mentioned and discussed the uniqueness of Domino as a proprietary (proprietary) development platform, just like the exclusive Komodo Island. In the version control field, Domino also has a unique "national condition ".

Difficult

Design elements such as form views are stored in the database in binary format. Compared with text files, binary files have difficulties in comparing version differences and merging. The invention of dxl makes it possible to convert the design elements and XML files. However, many bugs in dxl have not been solved for a long time, and the accuracy of mutual conversion cannot be guaranteed. It was not until R9 was launched that IBM had confidence in dxl and added its version control feature in designer.

In a mainstream programming language development environment, all files are in text format, and the version control system only needs to process files and folders. It takes a lot of weeks to reach the initial environment of the version control system under the domino platform. Designer first maps the design elements in the database to a virtual file system. For example, a form person is mapped to the file forms \ person in the database path. form. After the desinger is migrated to the eclipse platform, a domino application is verified and compiled as a Java project, and the design elements are displayed and modified using various views and editors of Eclipse, eclipse reads and writes this virtual file system. In the conversion process from design elements to files, elements such as forms and outlines based on user interfaces are converted into XML files through dxl; script Library (the Java Script library is an exception) java design elements and xpages are parsed into two or more files to accommodate the design elements of the Code. The first is the text files that contain the code and the configuration itself, the other is the metadata file that records the metadata of design elements. For example, an xpage named task is converted into task. xsp and task. xsp. Metadata. The content of the former is exactly the same as that seen in the source code view of the xpages editor.

To allow the version control tool outside designer to access this virtual file system, R9 adds a set of features, which can be used to set a local folder to synchronize the content with the virtual file system. In this way, the version control system is faced with a file system that is no different from other projects. It makes any changes to the file system content, if the version is switched or merged, it is detected by the designer and automatically converted back to the design element.

With this automatic bidirectional conversion between design elements and text files that are transparent to users, you can use any version control tool for the Notes application. However, the binary format does not completely solve the problem. The version control tool can compare the differences between two versions of a form, but the result is that the Notes programmer is not used to and is not easy to read XML. The reason is that Domino is not transformed into an XML format to record design elements. dxl just barely outputs them as XML, many of the contents are only displayed in character encoding using the <rawitemdata> component. For example, the layout information of a form is recorded in the $ body field. After the form is converted to XML, no Div or table like HTML is displayed, but a bunch of character codes are displayed.

<Item name = '$ body' Sign = 'true'> <rawitemdata type = '1'> gqkc/logs/xuaaqaackfkbwluv3jpdgvyczoa3qyaair // logs/1 qajwabb Signature + F/wgaaqaacoecgwqbaix/eaabaaakv3jpdgvyczrdbgaaiv // signature ...... </Rawitemdata>

Such XML is non-real-name and has little difference with the binary format. It is not for people to read. Only elements converted back to the design can be interpreted by the Notes client or server. If the difference between version control tools lies in such a character encoding entity, the programmer cannot determine its meaning. Similarly, when the merger of the same design element encounters a conflict, the programmer cannot intuitively understand the content to resolve it. Only the comparison and merging functions of the design elements of the Code class can exert the power.

In summary, the version control of Domino applications can be used only for single-person development. In team development scenarios, common comparisons and their respective branch versions are always limited.

Requirement

The source code management of Domino applications has never been well solved, but notes programmers seem to disagree, and even many people have never realized the needs of version control systems such as git. The reason also comes from the particularity of the domino platform. As a rapid development environment, Domino provides basic functions (such as off-the-shelf user management, permission management, integration with emails, and views), saving a lot of user code. On the other hand, the limitations of databases and systems make Domino only suitable for development in some fields, and the systems made will not be as large as general languages such as Java's large-scale projects. Therefore, a domino application usually has a small amount of code. Finally, the Code of Domino applications is highly coupled. Before xpages was introduced, data design, user interface, and business logic of many systems were all mixed together, even if xpages was used, we still need to have a good design to avoid mixing the view layer with the business layer. The low degree of code modularization also causes obstacles for simultaneous development by many people. So even in large companies that rely heavily on Domino, projects that require team development are rare (of course, it is common for a project team to have multiple people responsible for requirements, testing, and development ), even such a project is the responsibility of multiple database members.

In short, on the one hand, the domino application is small in size, the visualization is high, and there is little need for collaborative development. On the other hand, the application of Version Control Systems in Domino is difficult in the past, and the results are insufficient. This does not mean that the domino application has never had version control, and many companies have also developed internal versions used to manage the domino database. However, this type of system stores the entire database as an attachment or file. You cannot efficiently switch versions, and cannot automatically compare differences and Merged Code. The Domino platform is insulated from the version control system for decades and will continue to stand alone in the foreseeable future.

Domino + git

As analyzed above, since R9, Domino designer has become possible for a version control system outside the application. Some enthusiastic foreign developers have also developed plug-ins that integrate designer with tools such as subversion. However, I have poured cold water on it. Such version control can be used to manage the historical Design During single-user development. If we want to exert more functions of version control, we will be constrained. This section describes how to use Domino + git.

Select the application to enable Version Control in the navigation view, right-click the application, and select team development from the shortcut menu. The first item in the sub-menu is set up source control for this application, in the subsequent dialog box, select a folder to hold the files converted and output by the application, such as D: \ Lotus \ notes \ data \ workspace \ task. The setting on the domino side is complete. The other items in the sub-menu are as the name suggests.

Next we can use git to do what we have mentioned above. Run git shell and transfer it to D: \ Lotus \ notes \ data \ workspace \ task (create a filtering file. gitignore manually ).

Git init: Creates a new repository.

Git Add.: compile all files into the index.

Git commit-M initial: The first commit. Your Domino application has been managed by git.

Git branch: the default master branch is displayed.

In the process of version management, it is interesting to look at the composition of the Notes application from the perspective of a group of files, and the changes to the files brought about by each modification. If you are interested, you can also push your repository to GitHub.

Version Control, git, and Domino