Collaboration and settings --- was Re: bug in latex export tutorial?

[Robert Goldman <rpgoldman@sift.info>]

On 4/30/11 Apr 30 -5:14 PM, Eric S Fraga wrote:
> Robert Goldman <rpgoldman@sift.info> writes:
> 
>> On 4/29/11 Apr 29 -1:21 PM, Nick Dokos wrote:
> 
> [...]
> 
>>> amsmath conflicts with wasysym (redefines \iint), so you have to
>>> redefine your headers to omit wasysym or include amsmath *first*: for
>>> some reason, if you \usepackage{amsmath} *before* you
>>> \usepackage{wasysym}, the error does not arise -- presumably, amsmath
>>> assumes that \iint is not defined beforehand, whereas wasysym does not
>>> make that assumption.
>>
>> The not-very-tasty solution I came up with was to put the following into
>> the local variables list at the foot of my file:
>>
>> # org-export-latex-default-packages-alist: (("AUTO" "inputenc" t) ("T1"
>> "fontenc" t) ("" "fixltx2e" nil) ("" "graphicx" t) ("" "longtable" nil)
>> ("" "float" nil) ("" "wrapfig" nil) ("" "soul" t) ("" "t1enc" t) (""
>> "textcomp" t) ("" "marvosym" t) ("" "amsmath" t) ("" "wasysym" t) (""
>> "latexsym" t) ("" "amssymb" t)
>> ("colorlinks=true,pdfstartview=FitV,linkcolor=blue,citecolor=blue,urlcolor=blue"
>> "hyperref" nil) "\\tolerance=1000")
>>
>> I put this in the file, rather than in my configuration, because it is
>> specific to the formatting of this file, and because I share this
>> document with others, who need to be able to export from it w/o having
>> to reconfigure their org-mode installations.
>>
>> I figure that someone can probably suggest a solution that is nicer than
>> that!
>>
>> Best,
>> r
> 
> From earlier this year on the mailing list, below is a solution
> which works if you more often than not want amsmath; i.e. it's not a
> solution for the use case you specify in which you want to share a
> single file etc.  However, it's worth repeating this solution for other
> use cases.

Is there any documentation any where about how people use Org-mode in
collaborative authoring?  I find myself not on solid ground
understanding how to ensure that my colleagues have the same
configuration.  For now, I resort to entries in the local variables
list, but this may not be the best solution....

One could hijack the directory locals, but that seems like The Wrong
Thing --- we should leave that to the individual user for his/her
preferences.  Possibly set up something that would be layered, so that
there are dir-locals that optionally load user-specific settings /after/
the dir-locals (i.e., a second layer of dir-locals)?

Is anyone else trying to do stuff like this?

best,
r