At Thu, 10 Jul 2014 09:52:13 -0700, Matt Welland wrote: > > [1 <multipart/alternative (7bit)>] > [1.1 <text/plain; UTF-8 (7bit)>] > > [1.2 <text/html; UTF-8 (quoted-printable)>] > What is allow-symlinks set to for you? From context it sounds like it is set > to yes. If so this > is *terrible* behavior and a bad bug. If it is set to 0 (IMHO an awful option > that is default > and should not even exist [i] ) then I think what you are seeing is the > expected behavior. > > [i] In my opinion what you put in to a revision control system should > *always* equal what you > get out. The default fossil behavior of treating symlinks as extensions to > the file tree > fundamentally violates this principle. No need to debate this again. The > fossil devs are > adament that this is what they want but for the context of this discussion I > wanted to mention > my views on this point again.
If the user doesn't want the contents of the symlink, then I would make one of the following suggestions: 1) Set allow-symlinks to "on", so that it will add the symlinks as files that are not followed, IIRC. This is probably the behavior that the OP wants. I'll admit that this setting should be the default, although I find "on" to be fairly useless for my applications. 2) Leave allow-symlinks on "off", and put any offending symlinks files in the ignore glob, which is particularly useful in the presence of a versioned .fossil-settings/ignore-glob file. I have done this for quite a while, and it has been quite effective and flexible. I don't really understand why people have such strong objections to this method. 3) If adding the file is a genuinely serious issue, consider if the symbolic link should even be in the path of the repository. I'm not trying to play devil's advocate here, but I am curious as to the scenario that the user faces. I assume that they don't have control over what is present in the working directory? (In which case, either #1 or #2 apply). What I don't really understand is, why does a user want the symlink itself? This is likely far less valuable than the data stored inside of the symlink, and likely lacks relevance on other systems. If the symlinks cannot be followed, then how is the user supposed to version data of a portion of the directory hierarchy below the current location? Further, if someone clones the repository on another unix machine, what happens if the path that it points to either doesn't exist, or points to something completely different? Second, versioning the symlink itself, rather than following it seems less portable to me. OSes other than UNIX may not necessarily have symbolic links, so when a user clones that repository from Windows, I'm not sure how the symbolic links would be represented. When they are followed, it just clones the raw files, so I see no portability issues in regard to solution #2. Someone brought up a ClearCase scenario, where the presence of versioned .fossil-settings/ignore-glob is an issue. In this case, I would presume that ClearCase doesn't have a way to exclude fossil centric files? In that case, suggestion #1 applies. But if that is an issue, then why aren't .fslckout and the repository itself issues as well? Tim _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
