From 88367bc78c5e253fd5d03c4e30251f3b40d4c48e Mon Sep 17 00:00:00 2001
From: Mohammad Akhlaghi <mohammad@akhlaghi.org>
Date: Wed, 1 Apr 2020 03:14:00 +0100
Subject: Completed first draft of group working in build directory

This section (of sharing a build directory between multiple members of the
project) is also a good features of Maneage.
---
 paper.tex | 25 +++++++++++++++++++++----
 1 file changed, 21 insertions(+), 4 deletions(-)

(limited to 'paper.tex')

diff --git a/paper.tex b/paper.tex
index 167dea3..ca88ec3 100644
--- a/paper.tex
+++ b/paper.tex
@@ -1314,17 +1314,34 @@ Propagating bug fixes or improvements in the low-level infrastructure to all pro
 As we started using it in more projects by more users, many bugs were found and improvements made.
 We would then implement it in Maneage and that fix would propagate to all other projects automatically in their next merge.
 
-Modern version control systems provide many more capabilities that can be exploited through Maneage, and the shared branch it has with \emph{all} projects that use it.
-For example a third project can easily merge various high-level components from different projects into its own branch, thus adding a temporal dimension to their data lineage.
+Other scenarios include a third project that can easily merge various high-level components from different projects into its own branch, thus adding a temporal dimension to their data lineage.
+Modern version control systems provide many more capabilities that can be exploited through Maneage in project management, thanks to the shared branch it has with \emph{all} projects that use it.
 
 
 
 
 
-\subsection{Collaborating with same build directory}
+\subsection{Multi-user collaboration on single build directory}
 \label{sec:collaborating}
 
-Because the project's source and build directories are separate, it is possible for different users to share a build directory, while working on their own separate branch of Maneage during a collaboration.
+Because the project's source and build directories are separate, it is possible for different users to share a build directory, while working on their own separate project branches during a collaboration.
+Similar to the parallel branch that is later merged in phase 1 of Figure \ref{fig:branching}.
+
+To give all users previlage, Maneage assumes that they are in the same (POSIX) user group of the system.
+All files built in the build directory are then automatically assigned to this user group, with read-write permissions for all group members (\inlinecode{-rwxrwx---}), through the \inlinecode{sg} and \inlinecode{umask} commands that are prepended to the call to Make.
+The \inlinecode{./project} script has a special \inlinecode{--group} option which activates this mode in both configuration and analysis phases.
+It takes the user group name as its argument and the built files will only be accessible by the group members, even when the shared location is accessible by people outside the project.
+
+When multiple project members are contributing on a shared build directory, they usually work on independent parts of the project which won't cause any conflict.
+When there is a conflict, a member can temporarily change the name of the part's top directory within their branch.
+For example if Alice is working on the \inlinecode{demo-plot.mk} (Figure \ref{fig:demoplotsrc}) in parallel with others, she can set \inlinecode{a2dir} to be \inlinecode{\$(texdir)/tools-per-year-alice}.
+Other project members can also compare her results in this way and once it is merged into the master branch, \inlinecode{a2dir} can be set to its original value.
+
+The project already applies this strategy for part of the project that runs \LaTeX{} to build the final report.
+This is because project members will usually also be editing their parts of the report/paper as they progress.
+To fix this, when the project is configured and built with \inlinecode{--group}, each project member's user-name will be appended to the \LaTeX{} build directury (which is under \inlinecode{\$(BDIR)/tex}).
+
+However, human error is inevitable, so when the project takes long in some phases, the user and group write-permission flags can be manually removed from the respective subdirectories under \inlinecode{\$(BDIR)} until the project is to be built from scratch; maybe for a test prior to submission.
 
 
 
-- 
cgit v1.2.1

