On Mon, Feb 13, 2017 at 07:10:52PM -0800, Joe Mistachkin wrote:
>
> Martin Gagnon wrote:
> >
> > Strange, "fossil add a_dir_symlink" doesn't works for the case #2 on my
> > actual repository, but if I try to reproduce the problem on a brand new
> > repo, everything works.. Probably I hit a strange corner case. I will
> > try to investigate a bit more..
> >
>
> I've added the 'test-file-environment' command to Fossil to help with
> figuring this stuff out. Also, it has an --open-config option which
> is useful.
>
Thanks for this Joe,
I didn't find something wrong using test-file-environment, my real repo
and my test repo show same things.
However, I decide to debug using gdb, and I found the reason why the
"fossil add symlink_dir" fail in my real repo (with case #2). I was able
to reproduce the same on a new test repository.
It happens that the symlink point to a directory containing a directory
that is the top of a checkout:
Example:
/dir1/dir2/main_ckout/dir_symlink
/dir1/dir2/dir3/other_ckout
where:
dir_symlink point to: ../../dir3
Inside add_cmd, vfile_scan(...) is called with "dir_symlink" here:
http://fossil-scm.org/index.html/artifact?ln=334&name=f23144d54a286503
Then, since vfile_scan() find "other_ckout" directory inside, it should
normally call himself recursively with "other_ckout" but in this case
"other_ckout" get skipped here:
http://fossil-scm.org/index.html/artifact?ln=542&name=f2ac27cd86e8ff0c
because it is the top of a checkout.
I'm not sure if this protection is necessary, but if it is, it doesn't
get triggered if the symlink point directly to "../../dir3/other_ckout"
since the "top of a checkout" check only happens for the recursive call.
I don't know if the top of a checkout *must* be skipped or not, but
right now there's something inconsistent with this rule.
Regards
--
Martin G.
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
