RADE

Synopsis

adl_solve_merge [object...|-file file] [-ws workspace_name] [-no_manual] [-h | -help | -?]

Usage

When a workspace is created with the [1] adl_mk_ws command, parameters are set automatically. To modify the parameters relatives to the merge's cases, you can run the [2] adl_set_merge command.
In a given workspace or in your current workspace, you can know what are the merges you have to resolve, running the [3] adl_ls_merge command.

To read more about merge's principle, you can see either the [4] "Merger User Interface article", either the [5] "Resolving Conflicting Changes article" with the merger article.

When conflicts must be resolved, it is possible to launch the command several times, as long as there are merges left. Each time the command is launched, there is a menu giving the merges to be resolved, allowing the selection of a merge. You can resolve merge by merge all the conflicts.

Several menus are available depending on the merges to resolve:

When the adl_solve_merge command is launched, it first displays the list of all the merges left, then a fist selection menu. Possible merge types are:

• File content (several workspace modified the same file at the same time)
• Move or rename file (the same file has been renamed/moved twice)

If a list of objects is specified in a file or in the command line, only merges concerning these objects are displayed and are to resolved.

Example:

Each type of merge is listed and is preceded by a number that you can enter as your choice, if you want to resolve this merge. It is possible to choose in any order, even to stop the command and launch it again later on (non resolved merges will be proposed again)

[Top]

Move/Rename merges

When a move/rename merge is chosen from the main menu, the command displays three (or more) paths to the concerned file:

• The common ancestor: it is the path to the file as it was existing before one of the workspace renamed it
• Version 1: it is the path to the file as it was in the first workspace who made the move/rename
• Version 2: it is the path to the file as it was in the second workspace who made the move/rename
• Version n: it is possible that more than two workspaces moved or renamed the same file at the same time. In this case, it doesn't change the way of resolving the merge: you have to choose an access path.

Example:

In our example, you see that the file: …/F3.cpp has been renamed in Fic3.cpp by a workspace, and has been renamed in File3.cpp by another workspace. You must finally choose a name for this file.
Note: the merge on the name of a file doesn't lead to an automatic impact analysis. The user must verify that the change of that name doesn't create compilation's problems.

[Top]

Content file merges

In the default mode, an interactive graphic merger is launched. The call to this merger can be refused in three cases:

• Either the file has been modified by more than two workspaces at the same time (the merger is never launched in that case)
• Either the file has been modified by two workspaces, but the user decides to resolve himself the merge of the file. He choose the correct version and the result file (see first step menu)
• Either the file is a binary file (see adl_ls_type command)

If the interactive merger is used, both three versions of the file are displayed (ancestor, version 1, version 2) and the interactive merger is automatically launched.

Example:

If the user decides to quit the merger without having resolved the conflict, the command automatically proposes the second menu, corresponding to a file content merger without any interactive merger (see right after)

When more than two versions of a same file must be merged, or when the merger has been stopped before the end of the merge, a menu is displayed. This menu proposes the projection of the different versions of the file in a temporary directory. It also proposes a file which will be considered as the result file of the merge.

Example:

[Top]

Refresh of the current image 

Merges are resolved one by one, without any impact on the content of the current image. 
Meanwhile, as soon as a merge has been resolved, a new choice will appear in the main menu; the possibility of refresh of the current image

Example:

[Top]

Remarks:

Once a first merge has been chosen from the main menu, the command successively proposes the others merges, either launching the interactive merger, either displaying the corresponding sous-menu.

When all merges are resolved the command stops automatically with a refresh of the current image.

If the command needs a temporary directory (case of content type merge, without the interactive merger), this directory is not automatically cleaned by the command when it ends. Several reasons explain this way of being:

• Once the files projected in this directory, the user has all his time to examine and build up another result file. If the command is stopped, it can be launched again, and it can find again the directory containing the result file.
• The user can give the path of an existing directory, which is out of question to clean up.

At least, the user is notified that this temporary directory won't be cleaned by the command. In the example there after, the user decides to resolve a content merge without the interactive merger.

Example:

[Top]

Important methodological advice

It seems very important to advise you not always to use the options: "LeftAll" and/or "RightAll".
You must not forget that, when you choose this way, you loose a modification on the file, without thinking of the right of this modification. This seams unacceptable in almost all cases (users don't often make a correction in a file which is useless).

This use can come from two distinct reasons:

  1) I don't know how I can resolve this merge

SCM answers to this question: a user can resolve the conflicts of another user, in another workspace. Launch the adl_solve_merge command giving as argument the name of the workspace in which you want to resolve the merge.

  2) I cannot manage the merge with the graphic merger; I prefer resolve this conflict on my own, with another graphic tool.

SCM answers to this question: a user can resolve the conflicts on his own, in his own directory. Launch the adl_solve_merge command, asking for the projection of the differents versions of the file in a temporary directory, and resolve the conflict with an external tool. To do this, follow the example below:

Example of use of adl_solve_merge with merge out of the SCM merger

---> SCM projects all the versions of the file in a temporary directory, always the same for this merge

---> In this case, the user gives himself time for thought and for the creation of the content result. He can give the result when the new adl_solve_merge is launched (with the option: F and enter the result file path)

[Top]

Options

adl_solve_merge accepts the following options:

[Top]

Examples

Resolving merges to be done in the current workspace "MyWs":

adl_ch_ws MyWs  adl_solve_merge

Resolving merges in the workspace "MyWs", with no merge left to do:

adl_solve_merge 
No merge in the workspace "MyWs"