On 5/15/12, James Masters <james.d.mast...@gmail.com> wrote: > Sorry, I missed the crucial step of adding and comitting dir_b as a > symlink. Please append this to my example above: > > % fsl add dir_b > ADDED dir_b > % fsl commit dir_b -m 'adding symlink' > ADDED dir_b > ... > % fsl ann dir_b/foo > fossil: no such file: dir_b/foo > The confusion is that dir_b is a symlink to dir_a and when I follow that > symlink for normal file operations, it operates upon the file as if it were > a normal dir/file at the OS level. But not with fossil.
To most applications, dir_a/foo and dir_b/foo are 2 seperate files. In Unix derived OSes, symbolic links are designed to be transparant to applications that are ignorant of sym links. You might argue that Fossil has a need to be aware of sym links, else you end up with 2 (or more) of the same file under different names (where name == the full path), but there are more complications. Even if sym links worked exactly the same in all OSes, how to treat any given sym link is an open question subject to a lot of debate. For me, sym links would be a way to reference the working copy of a shared subproject in a project's working copy. While SVN's way of handling external references works, in my experience, it is too easy to end up with multiple working copies of the same shared project, so even with that usage model, there are complications. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
