stow/TODO

* Split core code into Stow.pm
* Add use strict / warnings to tests
* Honour .no-stow-folding and --no-folding
* Support ignore lists in files
*** Implement.
*** Add documentation about ignore lists.
***** Justification for having stow ignore lists independently of VCS ignore lists
******* If a file is in the VCS ignore list for its containing repo
********* generated during development
        probably shouldn't be stowed
********* generated during compilation / install
*********** could be an intermediary file
          again, probably shouldn't be stowed
*********** but most likely a file to install
          e.g. compiled binary/library/docs - should be stowed
******* If a file is not in the VCS ignore list for its containing repo
********* it's probably tracked by the VCS - part of the repo
********* could intended for end use
*********** e.g. script/config file requiring no modifications, docs
        should be stowed
********* or intended only to be used during compilation / build phase
        shouldn't be stowed
*** (Eventually) rsync-like include/exclude lists instead of ignore lists
* Add semi-automatic conflict resolution
*** STOW_RESOLVE_CONFLICTS="non_stow_symlinks=t stow_symlinks=r"
*** Add documentation about conflict resolution
* Make CPAN-friendly via Module::Build
*** Include test-time dependencies on Test::More and Test::Output
* Finish 'Deferring' section of manual
* get account on fencepost.gnu.org (email accounts@gnu.org) 
  set up copyright papers? 
  'assign.future' and 'request-assign.future.manual'

* Figure out what needs the option 'nostow' 'notstowed'. Can they be removed?

* _texi2man_ needs author/copyright/license to be completed

* Update http://directory.fsf.org/project/stow/

* Update savannah CVS

* Check that all email addresses are working: need an account on fenchpost for
  this bug-stow@gnu.org, help-stow@gnu.org

* Get some pre-testers: need to find appropriate mailing list?

* Announce release on info-gnu@gnu.org.

* Autodetect "foreign" stow directories

From e-mail with meyering@na-net.ornl.gov:

    > My /usr/local/info equivalent is a symlink to /share/info
    > because I want installs on all systems to put info files in that
    > directory.  With that set-up, stow chokes on fact that
    > /usr/local/info is a symlink.

    [...] Stow is designed to be paranoid about modifying anything it
    doesn't "own."  If it finds a symlink in the target tree (e.g.,
    /usr/local/info) which doesn't point into the stow tree, its
    paranoid response is to leave it the hell alone.  But I can see in
    this case how traversing the link and populating the directory on
    the far end would be OK.  Question: is that a special
    circumstance, or would it always be OK to populate the far end of
    a symlink in the target tree (when the symlink points to a
    directory in a context where a directory is needed)?  And: if it's
    a special circumstance requiring a command-line option, should the
    option be a mere boolean (such as, "--traverse-target-links") or
    should it be an enumeration of which links are OK to traverse
    (such as, "--traversable='info man doc'")?

Does Version 2 fix this? (Kal)
I think that because it never needs to create /usr/local/info,
it only needs to check the ownership of links that it _operates_ on,
not on all the elements of the path.

* emacs local variables
  Local Variables:
  mode: org
  End: