It is unclear from the documentation what this switch actually does, and I
unfortunately do not have time at the moment to read the code.
I use Linux and MacOSX and use symlinks to directories very heavily, so am
a little worried about what this change does. I never explicitly use this
switch.
I want a symlink to behave in fossil like it does in the Unix find command
- i.e. stop at a symlink without a --follow switch, and like it does in the
Unix tar command (which should be the model - if I `fossil add foo` it
should reference the same things as `tar cf - foo`). So addremove, for
example should not add things in the linked-so directory. One of the
things I often have is a symlink to ../TeX which points to a separate
working directory for (La)TeX support files. Once (a year or 2 ago) I was
setting up a new repo in fossil and did an addremove and it added all the
files in that directory and it was a bit of a pain to clean up. Since then
I never use addremove because I don't trust it not to make work for me.
Thanks again for this fabulous tool!
../Dave
On 24 August 2017 at 05:50, Johan Kuuse <jo...@kuu.se> wrote:
> Hi,
>
> Minimal fix: remove unused variable in Check-in [92ea6183]
>
>
> Index: src/file.c
> ==================================================================
> --- src/file.c
> +++ src/file.c
> @@ -626,11 +626,11 @@
> **
> ** On success, return zero. On error, return errorReturn if
> positive, otherwise
> ** print an error message and abort.
> */
> int file_mkfolder(const char *zFilename, int forceFlag, int errorReturn){
> - int i, nName, rc = 0;
> + int nName, rc = 0;
> char *zName;
>
> nName = strlen(zFilename);
> zName = mprintf("%s", zFilename);
> nName = file_simplify_name(zName, nName, 0);
>
>
> BR,
> Johan
>
>
> On Wed, Aug 23, 2017 at 6:33 PM, Richard Hipp <d...@sqlite.org> wrote:
> > On 8/23/17, Richard Hipp <d...@sqlite.org> wrote:
> >> The problem originates at this check-in:
> >> https://fossil-scm.org/fossil/timeline?c=2375d6cbce933267
> >
> > I do not understand what benefit the check-in above provides. But it
> > does definitely change the semantics of a lot of operations,
> > complicate the code, and introduce bugs. So I am inclined to back
> > that change out.
> >
> > If you are using the --no-dir-symlinks option and/or think it should
> > remain in the code, then you have 24 hours to make your case. In the
> > absence of a compelling reason to keep the --no-dir-symlinks, and a
> > promise for fixes to the code, I will back out that capability at the
> > conclusion of the comment period.
> > --
> > D. Richard Hipp
> > d...@sqlite.org
> > _______________________________________________
> > fossil-dev mailing list
> > fossil-dev@mailinglists.sqlite.org
> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
> _______________________________________________
> fossil-users mailing list
> fossil-us...@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
_______________________________________________
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
