Patent Description:
In a version control systems (VCS), branches of a version can be merged. The branches are divergent versions of the same content base (such as source code or documentation). After a merge has completed, a user may wish to revert, or undo, this merge in order to again separate the state of the branches to the way they were before the merge. However, current version control systems do not allow for shared history to be rewritten. Both of the branches can be re-used after the merge (e.g., both branches are referred to as "long-lived"). This undo operation can lead to unintended consequences upon the next merge of the two branches, (e.g., changes disappearing).

<CIT> discloses a system and method for backing out changes via a version control system.

The description that follows describes systems, methods, techniques, instruction sequences, and computing machine program products that illustrate example embodiments of the present subject matter. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide an understanding of various embodiments of the present subject matter. It will be evident, however, to those skilled in the art, that embodiments of the present subject matter may be practiced without some or other of these specific details. Examples merely typify possible variations. Unless explicitly stated otherwise, structures (e.g., structural Components, such as modules) are optional and may be combined or subdivided, and operations (e.g., in a procedure, algorithm, or other function) may vary in sequence or be combined or subdivided.

In a version control systems (VCS), branches are divergent versions of the same content base (such as source code or documentation). The branches can be merged. After a merge has completed, a user may wish to revert, or undo, this merge in order to again separate the state of the branches to the way they were before the merge. However, the VCS may not allow for shared history to be rewritten. Both branches can be re-used after the merge (e.g., both branches are "long-lived"). The undo operation can lead to unintended consequences upon the next merge of the two branches (e.g., changes suddenly disappearing).

The present application describes a solution to this problem by orchestrating an automatic revert of the merge which is immediately followed by a "patch" to the state of the version control system so that subsequent merges do not result in the aforementioned consequences. In one example embodiment, the present application describes an example of altering the version control "tree" or "DAG (Directed Acyclic Graph)" so that the next merge of these branches chooses a "valid" merge-base (e.g., the merge-base that was used for the very same merge that is being reverted).

Manually performing a revert of a merge without severe consequences can be difficult. As such, developers either avoid using long-lived branches, or avoid performing reverts of merges altogether. The present application describes a system that reverts merges under conditions that can be safely performed, automatically.

Example advantages of the present system include:.

In one example embodiment, a system for safely reverting merges across branches in version control systems where shared history cannot be rewritten is described. A computer-implemented method, comprises: identifying a first merge base at a trunk, the first merge base merging with a branch of the trunk; identifying, at the branch, a second merge base, subsequent to the first merge base, the second merge base merging with the trunk; forming a merge base patch branch from the branch at the second merge base, the merge base patch branch including a copy of the first merge base; merging the merge base patch branch with the trunk; and merging the merge base patch branch with the branch.

As a result, one or more of the methodologies described herein facilitate solving the technical problem of efficiently accessing, updating, and storing data in a data storage device. As such, one or more of the methodologies described herein may obviate a need for certain efforts or computing resources that otherwise would be involved in data management systems that have been designed for data access patterns where information is written once and is read multiple times through the lifetime of the data set. As a result, resources used by one or more machines, databases, or devices (e.g., within the environment) may be reduced. Examples of such computing resources include Processor cycles, network traffic, memory usage, data storage capacity, power consumption, network bandwidth, and cooling capacity.

<FIG> is a diagrammatic representation of a network environment <NUM> in which some example embodiments of the present disclosure may be implemented or deployed. One or more application servers <NUM> provide server-side functionality via a network <NUM> to a networked user device, in the form of a client device <NUM>. The client device <NUM> includes a web client <NUM> (e.g., a browser), a programmatic client <NUM> (e.g., a software development application) that is hosted and executed on the client device <NUM>.

An Application Program Interface (API) server <NUM> and a web server <NUM> provide respective programmatic and web interfaces to application servers <NUM>. A specific application server <NUM> hosts a version control system <NUM>, and a safe revert module <NUM>. Each application may further include additional Components, modules, and applications.

The version control system <NUM> includes, for example, a system that records changes to a file or set of files over time so that specific versions can be later recalled later. The version control system <NUM> may also be referred to as revision control, source control, or source code management. The version control system <NUM> is responsible for managing changes to computer programs, documents, large web sites, or other collections of information. One example of version control is a Component of software configuration management.

Changes are usually identified by a number or letter code, termed the "revision number", "revision level", or simply "revision". For example, an initial set of files is "revision <NUM>". When the first change is made, the resulting set is "revision <NUM>", and so on. Each revision is associated with a timestamp and the person making the change. Revisions can be compared, restored, and with some types of files, merged.

The need for a logical way to organize and control revisions has existed for almost as long as writing has existed, but revision control became much more important, and complicated, when the era of computing began. Today, the most capable (as well as complex) revision control systems are those used in software development, where a team of people may concurrently make changes to the same files.

The version control system <NUM> are commonly run as stand-alone applications. In other examples, version control operations from the version control system <NUM> can be embedded in various types of software such as word Processors and spreadsheets, collaborative web docs and in various content management systems. Revision control allows for the ability to revert a document to a previous revision.

The safe revert module <NUM> provides a mechanism for safely reverting merges across long-lived branches in version control systems where shared history cannot be rewritten is described. In one example embodiment, the safe revert module <NUM> orchestrates an automatic revert of the merge which is immediately followed by a "patch" to the state of the version control system so that subsequent merges do not result in the aforementioned consequences. This is achieved primarily by altering the version control "tree" or "DAG (Directed Acyclic Graph)" so that the next merge of these branches will choose a "valid" merge-base (e.g., namely, the merge based that was used for the very same merge that is being reverted).

The version control system <NUM> and the safe revert module <NUM> communicate with the programmatic client <NUM> via the programmatic interface provided by the Application Program Interface (API) server <NUM>. In another example, the version control system <NUM> and the safe revert module <NUM> communicate with the web client <NUM> via the web server <NUM>.

The application server <NUM> is shown to be communicatively coupled to database servers <NUM> that facilitates access to an information storage repository or databases <NUM>. In an example embodiment, the databases <NUM> include storage devices that store information to be processed by the version control system <NUM>, and the safe revert module <NUM>. In another example embodiment, the databases <NUM> include storage devices that store branch versions configured by the safe revert module <NUM>.

The third-party application <NUM> stores a third-party application <NUM>. The third-party application <NUM> executing on a third-party server <NUM> is shown as having programmatic access to the application server <NUM> via the programmatic interface provided by the Application Program Interface (API) server <NUM>. For example, the third-party application <NUM>, using information retrieved from the application server <NUM>, may support one or more features or functions on a website hosted by the third party. In another example, the third-party server <NUM> may perform some of the functions of the safe revert module <NUM>. In yet another example, the third-party application <NUM> may store the version control system <NUM> and the safe revert module <NUM>.

<FIG> is a block diagram illustrating the safe revert module <NUM> in accordance with one example embodiment. The safe revert module <NUM> includes a revert commit detector module <NUM> and a merge base patch branch module <NUM>. The revert commit detector module <NUM> detects a revert commit operation on a trunk of a tree. For example, the revert commit detector module <NUM> detects that the merge of source code from a branch to a trunk of the tree. As previously described above, such operation can potentially hazardous should a break be detected in the trunk as a result of the merge.

The merge base patch branch module <NUM> forms a new branch off the branch of the trunk. The new branch may also be referred to as a new "merge base patch branch. " A node of the merge base patch branch includes the same logic content as a previous merge base of the trunk. The operation of the merge base patch branch module <NUM> is described in more detail below with respect to <FIG> and <FIG>.

<FIG> illustrates a flow diagram <NUM> in accordance with one example embodiment. Operations in the flow diagram <NUM> may be performed by the safe revert module <NUM> using Components (e.g., modules, engines) described above with respect to <FIG>. Accordingly, the flow diagram <NUM> is described by way of example with reference to the safe revert module <NUM>. However, it shall be appreciated that at least some of the operations of the flow diagram <NUM> may be deployed on various other hardware configurations or be performed by similar Components residing elsewhere.

In block <NUM>, the safe revert module <NUM> identifies a first merge base of the trunk prior to a second merge base of the branch. In block <NUM>, the safe revert module <NUM> forms a patch branch off the branch. The patch branch includes a copy of the first merge base. In block <NUM>, the safe revert module <NUM> performs a merge of the trunk with the branch using the copy of the first merge based on the patch branch.

It is to be noted that other embodiments may use different sequencing, additional or fewer operations, and different nomenclature or terminology to accomplish similar functions. In some embodiments, various operations may be performed in parallel with other operations, either in a synchronous or asynchronous manner. The operations described herein were chosen to illustrate some principles of operations in a simplified form.

In block <NUM>, the safe revert module <NUM> merges changes from a merge base of a trunk to a branch. In block <NUM>, the safe revert module <NUM> merge changes from a merge base of a branch to the trunk. In block <NUM>, in response to the revert commit detector module <NUM> detecting the merge changes from the merge base of the branch to the trunk, the merge base patch branch module <NUM> forms a merge base patch branch that includes a copy of the merge base of the trunk. In block <NUM>, the merge base patch branch module <NUM> merges the merge base patch branch with the trunk. In block <NUM>, the merge base patch branch module <NUM> merges the merge base patch branch with the branch.

<FIG> illustrates an example of merges in accordance with one example embodiment. Level <NUM> represents a trunk <NUM> of a tree. Level <NUM> represents a branch <NUM> of the tree. Each node of the tree represents a revision of a source code within the respective trunk <NUM> or branch <NUM>. For example, the trunk <NUM> includes changes <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> of an application. The branch <NUM> includes changes <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> of a sub-application of the application.

The source code from merge base <NUM> from the trunk <NUM> is merged with node <NUM> of the branch <NUM>. The node <NUM> includes previous source code changes (e.g., revision x1 from node <NUM>, revision x2 from node <NUM>, and revision x3 from node <NUM>) that are merged with source code from merge base <NUM>.

The merge base <NUM> of the branch <NUM> merges back with node <NUM> resulting in a break (malfunction) of the source code at node <NUM>. The break is detected at node <NUM>. At node <NUM>, a revert commit of the merge (from merge base <NUM> to node <NUM>) is performed to remove the changes of merge base <NUM> to the trunk <NUM>.

A danger zone <NUM> includes node <NUM>, node <NUM>, node <NUM>, node <NUM>, and parent <NUM>. A merge from a node within the danger zone <NUM> (e.g., merge from parent <NUM> to node <NUM>) could result in causing damages to the branch <NUM> because the revert commit at node <NUM> would unintentionally revert changes X1 of node <NUM>, X2 of node <NUM>, and X3 of node <NUM>, as well as any other changes from the branch <NUM> since the last merge from merge base <NUM> to node <NUM>.

<FIG> illustrates an example of safe merges in accordance with one example embodiment. Level <NUM> represents a <NUM> of a tree. Level <NUM> represents a branch <NUM> of the tree. Each node of the tree represents a revision of a source code within the respective trunk <NUM> or branch <NUM>. For example, the trunk <NUM> includes changes <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>. The branch <NUM> includes changes <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>.

The source code from merge base <NUM> from trunk <NUM> is merged with node <NUM> of the branch <NUM>. The node <NUM> includes previous source code changes (e.g., revision x1 at node <NUM>, revision x2 at node <NUM>, revision x3 at node <NUM>) that are merged with source code from merge base <NUM>.

The revert commit detector module <NUM> detects the revert commit performed at node <NUM>. In another example, the revert commit detector module <NUM> detects a merge from the branch <NUM> back to the trunk <NUM> (e.g., merge from merge base <NUM> to node <NUM>). In response to the branch-to-trunk merge, the merge base patch branch module <NUM> forms a new branch (e.g. merge base patch branch <NUM>) off the merge base <NUM>. The merge base patch branch <NUM> includes a copy of the source code from the last node being merged from the trunk <NUM> to the branch <NUM>: merge base <NUM>. As such, merge base patch branch <NUM> is a child of merge base <NUM>. The merge base patch branch <NUM> connects back to node <NUM> of trunk <NUM> and node <NUM> of branch <NUM>.

In another example, the revert commit detector module <NUM> detects the merge from merge base <NUM> to node <NUM> and in response, the merge base patch branch module <NUM> forms the merge base patch branch <NUM>. In yet another example, the revert commit detector module <NUM> detects a revert commit operation at node <NUM> and in response, the merge base patch branch module <NUM> forms the merge base patch branch <NUM>. In yet another example, the revert commit detector module <NUM> detects a break at node <NUM> and in response, the merge base patch branch module <NUM> forms the merge base patch branch <NUM>.

A later merge, after the node <NUM>, from the trunk <NUM> to branch <NUM> is performed. For example, source code from parent <NUM> is merged with node <NUM>. The merge base patch branch <NUM> is chosen as the merge base. As the child of merge base <NUM>, and as an ancestor of both parent <NUM> and node <NUM>, merge base patch branch <NUM> is picked as the merge base for the next merge (e.g., parent <NUM> to node <NUM>). The next merge will logically function as if the merge base <NUM> was chosen as the merge base, preventing the above-described "unintentional backout" scenario (acting as if a defective merge did not occur).

The software architecture <NUM> is supported by hardware such as a machine <NUM> that includes Processors <NUM>, memory <NUM>, and I/O Components <NUM>.

The operating system <NUM> manages hardware resources and provides common services. The operating system <NUM> includes, for example, a kernel <NUM>, services <NUM>, and drivers <NUM>. The kernel <NUM> acts as an abstraction layer between the hardware and the other software layers. For example, the kernel <NUM> provides memory management, Processor management (e.g., scheduling), Component management, networking, and security settings, among other functionality. The services <NUM> can provide other common services for the other software layers. The drivers <NUM> are responsible for controlling or interfacing with the underlying hardware. For instance, the drivers <NUM> can include display drivers, camera drivers, BLUETOOTH® or BLUETOOTH® Low Energy drivers, flash memory drivers, serial communication drivers (e.g., Universal Serial Bus (USB) drivers), WI-FI® drivers, audio drivers, power management drivers, and so forth.

The libraries <NUM> provide a low-level common infrastructure used by the applications <NUM>. The libraries <NUM> can include system libraries <NUM> (e.g., C standard library) that provide functions such as memory allocation functions, string manipulation functions, mathematic functions, and the like. In addition, the libraries <NUM> can include API libraries <NUM> such as media libraries (e.g., libraries to support presentation and manipulation of various media formats such as Moving Picture Experts Group-<NUM> (MPEG4), Advanced Video Coding (H. <NUM> or AVC), Moving Picture Experts Group Layer-<NUM> (MP3), Advanced Audio Coding (AAC), Adaptive Multi-Rate (AMR) audio codec, Joint Photographic Experts Group (JPEG or JPG), or Portable Network Graphics (PNG)), graphics libraries (e.g., an OpenGL framework used to render in two dimensions (2D) and three dimensions (3D) in a graphic content on a display), database libraries (e.g., SQLite to provide various relational database functions), web libraries (e.g., WebKit to provide web browsing functionality), and the like. The libraries <NUM> can also include a wide variety of other libraries <NUM> to provide many other APIs to the applications <NUM>.

The frameworks <NUM> provide a high-level common infrastructure that is used by the applications <NUM>. For example, the frameworks <NUM> provide various graphical user interface (GUI) functions, high-level resource management, and high-level location services. The frameworks <NUM> can provide a broad spectrum of other APIs that can be used by the applications <NUM>, some of which may be specific to a particular operating system or platform.

In an example embodiment, the applications <NUM> may include a home application <NUM>, a contacts application <NUM>, a browser application <NUM>, a book reader application <NUM>, a location application <NUM>, a media application <NUM>, a messaging application <NUM>, a game application <NUM>, and a broad assortment of other applications such as a third-party application <NUM>. The applications <NUM> are programs that execute functions defined in the programs. Various programming languages can be employed to create one or more of the applications <NUM>, structured in a variety of manners, such as object-oriented programming languages (e.g., Objective-C, Java, or C++) or procedural programming languages (e.g., C or assembly language). In a specific example, the third-party application <NUM> (e.g., an application developed using the ANDROID™ or IOS™ software development kit (SDK) by an entity other than the vendor of the particular platform) may be mobile software running on a mobile operating system such as IOS™, ANDROID™, WINDOWS® Phone, or another mobile operating system. In this example, the third-party application <NUM> can invoke the API calls <NUM> provided by the operating system <NUM> to facilitate functionality described herein.

<FIG> is a diagrammatic representation of the machine <NUM> within which instructions <NUM> (e.g., software, a program, an application, an applet, an app, or other executable code) for causing the machine <NUM> to perform any one or more of the methodologies discussed herein may be executed. For example, the instructions <NUM> may cause the machine <NUM> to execute any one or more of the methods described herein. The instructions <NUM> transform the general, non-programmed machine <NUM> into a particular machine <NUM> programmed to carry out the described and illustrated functions in the manner described. The machine <NUM> may operate as a standalone device or may be coupled (e.g., networked) to other machines. In a networked deployment, the machine <NUM> may operate in the capacity of a server machine or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine <NUM> may comprise, but not be limited to, a server computer, a client computer, a personal computer (PC), a tablet computer, a laptop computer, a netbook, a set-top box (STB), a PDA, an entertainment media system, a cellular telephone, a smart phone, a mobile device, a wearable device (e.g., a smart watch), a smart home device (e.g., a smart appliance), other smart devices, a web appliance, a network router, a network switch, a network bridge, or any machine capable of executing the instructions <NUM>, sequentially or otherwise, that specify actions to be taken by the machine <NUM>. Further, while only a single machine <NUM> is illustrated, the term "machine" shall also be taken to include a collection of machines that individually or jointly execute the instructions <NUM> to perform any one or more of the methodologies discussed herein.

The machine <NUM> may include Processors <NUM>, memory <NUM>, and I/O Components <NUM>, which may be configured to communicate with each other via a bus <NUM>. In an example embodiment, the Processors <NUM> (e.g., a Central Processing Unit (CPU), a Reduced Instruction Set Computing (RISC) Processor, a Complex Instruction Set Computing (CISC) Processor, a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), an ASIC, a Radio-Frequency Integrated Circuit (RFIC), another Processor, or any suitable combination thereof) may include, for example, a Processor <NUM> and a Processor <NUM> that execute the instructions <NUM>. The term "Processor" is intended to include multi-core Processors that may comprise two or more independent Processors (sometimes referred to as "cores") that may execute instructions contemporaneously. Although <FIG> shows multiple Processors <NUM>, the machine <NUM> may include a single Processor with a single core, a single Processor with multiple cores (e.g., a multi-core Processor), multiple Processors with a single core, multiple Processors with multiples cores, or any combination thereof.

The memory <NUM> includes a main memory <NUM>, a static memory <NUM>, and a storage unit <NUM>, both accessible to the Processors <NUM> via the bus <NUM>. The instructions <NUM> may also reside, completely or partially, within the main memory <NUM>, within the static memory <NUM>, within machine-readable medium <NUM> within the storage unit <NUM>, within at least one of the Processors <NUM> (e.g., within the Processor's cache memory), or any suitable combination thereof, during execution thereof by the machine <NUM>.

The I/O Components <NUM> may include a wide variety of Components to receive input, provide output, produce output, transmit information, exchange information, capture measurements, and so on. The specific I/O Components <NUM> that are included in a particular machine will depend on the type of machine. For example, portable machines such as mobile phones may include a touch input device or other such input mechanisms, while a headless server machine will likely not include such a touch input device. It will be appreciated that the I/O Components <NUM> may include many other Components that are not shown in <FIG>. In various example embodiments, the I/O Components <NUM> may include output Components <NUM> and input Components <NUM>. The output Components <NUM> may include visual Components (e.g., a display such as a plasma display panel (PDP), a light emitting diode (LED) display, a liquid crystal display (LCD), a projector, or a cathode ray tube (CRT)), acoustic Components (e.g., speakers), haptic Components (e.g., a vibratory motor, resistance mechanisms), other signal generators, and so forth. The input Components <NUM> may include alphanumeric input Components (e.g., a keyboard, a touch screen configured to receive alphanumeric input, a photo-optical keyboard, or other alphanumeric input Components), point-based input Components (e.g., a mouse, a touchpad, a trackball, a joystick, a motion sensor, or another pointing instrument), tactile input Components (e.g., a physical button, a touch screen that provides location and/or force of touches or touch gestures, or other tactile input Components), audio input Components (e.g., a microphone), and the like.

In further example embodiments, the I/O Components <NUM> may include biometric Components <NUM>, motion Components <NUM>, environmental Components <NUM>, or position Components <NUM>, among a wide array of other Components. For example, the biometric Components <NUM> include Components to detect expressions (e.g., hand expressions, facial expressions, vocal expressions, body gestures, or eye tracking), measure biosignals (e.g., blood pressure, heart rate, body temperature, perspiration, or brain waves), identify a person (e.g., voice identification, retinal identification, facial identification, fingerprint identification, or electroencephalogram-based identification), and the like. The motion Components <NUM> include acceleration sensor Components (e.g., accelerometer), gravitation sensor Components, rotation sensor Components (e.g., gyroscope), and so forth. The environmental Components <NUM> include, for example, illumination sensor Components (e.g., photometer), temperature sensor Components (e.g., one or more thermometers that detect ambient temperature), humidity sensor Components, pressure sensor Components (e.g., barometer), acoustic sensor Components (e.g., one or more microphones that detect background noise), proximity sensor Components (e.g., infrared sensors that detect nearby objects), gas sensors (e.g., gas detection sensors to detection concentrations of hazardous gases for safety or to measure pollutants in the atmosphere), or other Components that may provide indications, measurements, or signals corresponding to a surrounding physical environment. The position Components <NUM> include location sensor Components (e.g., a GPS receiver Component), altitude sensor Components (e.g., altimeters or barometers that detect air pressure from which altitude may be derived), orientation sensor Components (e.g., magnetometers), and the like.

Communication may be implemented using a wide variety of technologies. The I/O Components <NUM> further include communication Components <NUM> operable to couple the machine <NUM> to a network <NUM> or devices <NUM> via a coupling <NUM> and a coupling <NUM>, respectively. For example, the communication Components <NUM> may include a network interface Component or another suitable device to interface with the network <NUM>. In further examples, the communication Components <NUM> may include wired communication Components, wireless communication Components, cellular communication Components, Near Field Communication (NFC) Components, Bluetooth® Components (e.g., Bluetooth®Low Energy), Wi-Fi® Components, and other communication Components to provide communication via other modalities. The devices <NUM> may be another machine or any of a wide variety of peripheral devices (e.g., a peripheral device coupled via a USB).

Moreover, the communication Components <NUM> may detect identifiers or include Components operable to detect identifiers. For example, the communication Components <NUM> may include Radio Frequency Identification (RFID) tag reader Components, NFC smart tag detection Components, optical reader Components (e.g., an optical sensor to detect one-dimensional bar codes such as Universal Product Code (UPC) bar code, multi-dimensional bar codes such as Quick Response (QR) code, Aztec code, Data Matrix, Dataglyph, MaxiCode, PDF417, Ultra Code, UCC RSS-2D bar code, and other optical codes), or acoustic detection Components (e.g., microphones to identify tagged audio signals). In addition, a variety of information may be derived via the communication Components <NUM>, such as location via Internet Protocol (IP) geolocation, location via Wi-Fi® signal triangulation, location via detecting an NFC beacon signal that may indicate a particular location, and so forth.

The various memories (e.g., memory <NUM>, main memory <NUM>, static memory <NUM>, and/or memory of the Processors <NUM>) and/or storage unit <NUM> may store one or more sets of instructions and data structures (e.g., software) embodying or used by any one or more of the methodologies or functions described herein. These instructions (e.g., the instructions <NUM>), when executed by Processors <NUM>, cause various operations to implement the disclosed embodiments.

The instructions <NUM> may be transmitted or received over the network <NUM>, using a transmission medium, via a network interface device (e.g., a network interface Component included in the communication Components <NUM>) and using any one of a number of well-known transfer protocols (e.g., hypertext transfer protocol (HTTP)). Similarly, the instructions <NUM> may be transmitted or received using a transmission medium via the coupling <NUM> (e.g., a peer-to-peer coupling) to the devices <NUM>.

Although an embodiment has been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader scope of the present disclosure. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings that form a part hereof, show by way of illustration, and not of limitation, specific embodiments in which the subject matter may be practiced. The embodiments illustrated are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. This Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims.

Such embodiments of the inventive subject matter may be referred to herein, individually and/or collectively, by the term "invention" merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or inventive concept if more than one is in fact disclosed. Thus, although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.

Claim 1:
A computer-implemented method in a Version Control System, VCS, the method comprising:
identifying (<NUM>) a first merge base (<NUM>) at a trunk (<NUM>), the first merge base merging with a branch (<NUM>) of the trunk, wherein the trunk and the branch are part of a tree of the VCS;
identifying (<NUM>), at the branch, a second merge base (<NUM>), subsequent to the first merge base, the second merge base merging with the trunk;
detecting a break at the trunk in response to the second merge base merging with the trunk;
performing a revert commit function at the trunk in response to detecting the break, said revert function commit being performed to remove the changes of the second merge base to the trunk;
forming (<NUM>) a merge base patch branch (<NUM>) from the branch at the second merge base, the merge base patch branch including a copy of the first merge base (<NUM>);
merging (<NUM>) the merge base patch branch with the trunk; and
merging (<NUM>) the merge base patch branch with the branch.