doc/distributed_bugtracking.txt

   1 ***********************
   2 Distributed Bugtracking
   3 ***********************
   4
   5 Usage Cases
   6 ===========
   7
   8 Case 1: Tracking the status of bugs in remote repo branches
   9 -----------------------------------------------------------
  10
  11 See the discussion in
  12 #bea86499-824e-4e77-b085-2d581fa9ccab/12c986be-d19a-4b8b-b1b5-68248ff4d331#.
  13 Here, it doesn't matter whether the remote repository is a branch of
  14 the local repository, or a completely separate project
  15 (e.g. upstream, ...).  So long as the remote project provides access
  16 via some REPO format, you can use::
  17
  18     $ be --repo REPO ...
  19
  20 to run your query, or::
  21
  22     $ be diff REPO
  23
  24 to see the changes between the local and remote repositories.
  25
  26
  27 Case 2: Importing bugs from other repositories
  28 ----------------------------------------------
  29
  30 Case 2.1: If the remote repository is a branch of the local repository::
  31
  32      $ <VCS> merge <REPO>
  33
  34 Case 2.2: If the remote repository is not a branch of the local repository
  35 (Hypothetical command)::
  36
  37     $ be import <REPO> <ID>
  38
  39
  40 Notes
  41 =====
  42
  43 Providing public repositories
  44 -----------------------------
  45
  46 e.g. for non-dev users.  These are just branches that expose a public
  47 interface (HTML, email, ...).  Merge and query like any other
  48 development branch.
  49
  50
  51 Managing permissions
  52 --------------------
  53
  54 Many bugtrackers implement some sort of permissions system, and they
  55 are certainly required for a central system with diverse user roles.
  56 However DVCSs also support the "pull my changes" workflow, where
  57 permissions are irrelevant.