hi all
is there any good reason for the recursive link in the externals/apple directory of the repository?
http://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/externals/apple...
mfg.asdr IOhannes
Yes, so that the help patches work with [apple/iodisplay] format when working on them.
.h
On Apr 7, 2008, at 7:43 AM, IOhannes m zmoelnig wrote:
hi all
is there any good reason for the recursive link in the externals/apple directory of the repository?
http://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/ externals/apple/apple
mfg.asdr IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
If you are not part of the solution, you are part of the problem.
Hans-Christoph Steiner wrote:
Yes, so that the help patches work with [apple/iodisplay] format when working on them.
hmm, since the help-patches depend on so many external libraries, why don't you just add ".." (or, if you prefer, the full path to .../trunk/externals) to your search path?
or, if this is no option, just make the link on your local machine.
the reason why i bring this up is, that i tried to zip the entire repository (on linux), and couldn't unzip it (on windows), obviously because of the over-long path. one could argue that this is just a problem of my usage of zip.
but then, the reason why i had to do it via zip is, that there is this bad file in the gridflow part of the repository (inv*-icon.png); one could argue as well, that i just shouldn't use NTFS (or w32, that is)
i believe that there shouldn't be any filenames unable to be restored on today's widely used filesystems. and i thinkthat recursion should be avoided on a filesystem level (esp. if there are alternatives)
just my 2¢ (i stop ranting now)
fgamdsr IOhannes
-
Hans-Christoph Steiner -
IOhannes m zmoelnig