view doc/libervia-cli/merge-request.rst @ 4231:e11b13418ba6

plugin XEP-0353, XEP-0234, jingle: WebRTC data channel signaling implementation: Implement XEP-0343: Signaling WebRTC Data Channels in Jingle. The current version of the XEP (0.3.1) has no implementation and contains some flaws. After discussing this on xsf@, Daniel (from Conversations) mentioned that they had a sprint with Larma (from Dino) to work on another version and provided me with this link: https://gist.github.com/iNPUTmice/6c56f3e948cca517c5fb129016d99e74 . I have used it for my implementation. This implementation reuses work done on Jingle A/V call (notably XEP-0176 and XEP-0167 plugins), with adaptations. When used, XEP-0234 will not handle the file itself as it normally does. This is because WebRTC has several implementations (browser for web interface, GStreamer for others), and file/data must be handled directly by the frontend. This is particularly important for web frontends, as the file is not sent from the backend but from the end-user's browser device. Among the changes, there are: - XEP-0343 implementation. - `file_send` bridge method now use serialised dict as output. - New `BaseTransportHandler.is_usable` method which get content data and returns a boolean (default to `True`) to tell if this transport can actually be used in this context (when we are initiator). Used in webRTC case to see if call data are available. - Support of `application` media type, and everything necessary to handle data channels. - Better confirmation message, with file name, size and description when available. - When file is accepted in preflight, it is specified in following `action_new` signal for actual file transfer. This way, frontend can avoid the display or 2 confirmation messages. - XEP-0166: when not specified, default `content` name is now its index number instead of a UUID. This follows the behaviour of browsers. - XEP-0353: better handling of events such as call taken by another device. - various other updates. rel 441
author Goffi <goffi@goffi.org>
date Sat, 06 Apr 2024 12:57:23 +0200
parents 524856bd7b19
children
line wrap: on
line source

===============================================
merge-request: create and manage merge requests
===============================================

Merge-request are used to propose some modifications to a project. They are generic and
are made to be used with several backends, but only Mercurial is implemented so far.

To prepare a merge request with Mercurial, you just need to have a clone of the project,
and do your modifications (either directly, or in a bookmark, a branch, or a MQ patch).

set
===

Create and publish a merge request. Once the modification on the project are done, simply
run the command from the repository (or specify its path with ``-r PATH, --repository
PATH``). If the project has set metadata (it can be done with a magic string in README),
you don't have to specify any service or node, it will be set automatically (but you still
can specify them if needed).

You may associate one or more labels to your request using ``-l LABELS, --label LABELS``.

By default, a confirmation is requested before publishing the request, you can publish
without confirmation by using the ``-f, --force`` flag.

If you have already done a merge request and you just want to update it, check its id and
specify it with ``-i ITEM, --item ITEM``, this will override the previous request with the
new updated one.

examples
--------

Publish a merge request (to be executed from the repository of the project you have
modified)::

  $ li merge-request set

Update an existing merge request, which has the id ``123`` (to be executed from the
reposiroty of the project you have modified)::

  $ li merge-request set -i 123

Do a merge request for repository at path ``~/some_project``, specifying a label
indicating it's work in progress (WIP)::

  $ li merge-request set -r ~/some_project --label WIP


get
===

Get and print one or more merge requests. By default only some metadata are shown (without
the patches), but you can use ``--verbose, -v`` to show details.

examples
--------

Show some metadata of last 5 merge requests::

  $ li merge-request get -M 5

Display details for merge request with id 456::

  $ li merge-request get -v -i 456


import
======

import a merge request into your project. You mainly have to be in the project repository
(or specify it using ``-r PATH, --repository PATH``) and to specify the id of the patch to
import (using ``-i ITEM, --item ITEM``). The behaviour depends of the type of the patch,
for Mercurial, the patch will be imported as `MQ`_ patch.

.. _MQ: https://www.mercurial-scm.org/wiki/MqExtension

example
-------

import the merge request with id 321::

  $ li merge-request import -i 321