Fix documentation regarding splitting of symlinks across multiple stow directories.
[gnu-stow.git] / TODO
blob01d6fdae5fe085075231148b5bd90466219d2bc1
1 * Prevent folding of directories which contain ignored files
2 * Honour .no-stow-folding and --no-folding
3 * Add semi-automatic conflict resolution
4 *** STOW_RESOLVE_CONFLICTS="non_stow_symlinks=t stow_symlinks=r"
5 *** Add documentation about conflict resolution
6 * get account on fencepost.gnu.org (email accounts@gnu.org) 
7   set up copyright papers? 
8   'assign.future' and 'request-assign.future.manual'
10 * Figure out what needs the files '.nonstow' and '.notstowed'. Can they be removed?
12 * Update http://directory.fsf.org/project/stow/
14 * Update savannah CVS
16 * Check that all email addresses are working: need an account on fenchpost for
17   this bug-stow@gnu.org, help-stow@gnu.org
19 * Get some pre-testers: need to find appropriate mailing list?
21 * Announce release on info-gnu@gnu.org.
23 * Autodetect "foreign" stow directories
25 From e-mail with meyering@na-net.ornl.gov:
27     > My /usr/local/info equivalent is a symlink to /share/info
28     > because I want installs on all systems to put info files in that
29     > directory.  With that set-up, stow chokes on fact that
30     > /usr/local/info is a symlink.
32     [...] Stow is designed to be paranoid about modifying anything it
33     doesn't "own."  If it finds a symlink in the target tree (e.g.,
34     /usr/local/info) which doesn't point into the stow tree, its
35     paranoid response is to leave it the hell alone.  But I can see in
36     this case how traversing the link and populating the directory on
37     the far end would be OK.  Question: is that a special
38     circumstance, or would it always be OK to populate the far end of
39     a symlink in the target tree (when the symlink points to a
40     directory in a context where a directory is needed)?  And: if it's
41     a special circumstance requiring a command-line option, should the
42     option be a mere boolean (such as, "--traverse-target-links") or
43     should it be an enumeration of which links are OK to traverse
44     (such as, "--traversable='info man doc'")?
46 Does Version 2 fix this? (Kal)
47 I think that because it never needs to create /usr/local/info,
48 it only needs to check the ownership of links that it _operates_ on,
49 not on all the elements of the path.
51 * emacs local variables
52   Local Variables:
53   mode: org
54   End: