Could i convince one of the devs more familiar with the symlinks bits refine Joerg's explanation below into one of the embedded docs? It's a pretty good explanation/summary, IMO.
On Fri, May 9, 2014 at 8:33 PM, j. van den hoff <veedeeh...@googlemail.com>wrote: > On Fri, 09 May 2014 19:45:01 +0200, Matt Welland <estifo...@gmail.com> > wrote: > > FYI, beware that there may be a bug with symlinks support in the more >> recent versions of fossil. I haven't reported it as I haven't had time to >> reproduce it but a couple of users have complained that when they >> clone/open a fossil that has allow-symlinks = true that the symlinks are >> replaced by the pointed to data in the check out. If they check out an >> older node then check out trunk the data is replaced by the expected >> symlinks. >> > > I'm not sure whether there is a bug here (except the one noted at the end > of this mail). > my reading of `fossil help set' and a small test I've done right now with > > This is fossil version 1.29 [5e47d555e4] 2014-04-30 16:35:21 UTC > > (note to developers: the `This is' in the "version" message should > go away in my view -- at least it would allow more seamless copy+paste > not disrupting the syntax of the text into which one copies ;-)) > > seems to verify this behaviour: > > 1. allow-symlinks off (default): > > a) > if the symlinks are ADDed and checkedin, > content is tracked across the links, i.e. as far as fossil is concerned > everything acts as if the actual files where local to the repo: > changes are noted, checkouts overwrite the actual files, not the symlinks. > this seems in accord with the documentation and sure is useful for the > purpose of tracking disseminated config files, e.g. > > b) > if this repo is cloned and opened, indeed the original files materialize > in the checkout, i.e. the symlink information is lost (probably never > was there in the repo?). I presume(...) this also does not contradict > the documentation. this seems to be the behavior you mention. > but this is not wrong per se. whether this behavior is ideal > is another question. one probably could argue for restoring symlinks at > this > point. > > 2. allow-symlinks on: > > a) > if the symlinks are ADDed and checkedin, > content is NOT tracked across the links, i.e. modifications of the > linked files are not noticed by fossil and cannot be checked in. > the "content" of the checkedin links (e.g. what you see with `fossil cat') > just is the path to the linked files. this seems in accord with the > documentation > > b) > if this repo is cloned and opened, links materialize using verbatim > the path stored as content in the original repo. > > all this seems quite consistent to me also 1.b) might not be what one > would prefer. > the only probably "real" bug for me is that in 2.b) above the generated > symlinks point _verbatim_ to the same location used in the original > creation of the links (instead of always using > the absolute paths). here is the catch: > if the links were not generated with absolute pathnames in the first > place, the links in the clone usually will > point to outer space (i.e. the links are invalid) which is totally useless > I'd say. > > > j. > > >> >> On Fri, May 9, 2014 at 10:00 AM, Stephan Beal <sgb...@googlemail.com> >> wrote: >> >> On Fri, May 9, 2014 at 6:30 PM, j. van den hoff < >>> veedeeh...@googlemail.com >>> > wrote: >>> >>> modified. so my understanding is when 'on' the softlinks are just >>>> maintained >>>> in the repo while when 'off' (the default) the system should behave >>>> like >>>> what you describe: >>>> track the changes across the softlinks (i.e. the "real content") and >>>> update >>>> _that_ content when doing a `fossil up'. or am I missing something? >>>> >>> >>> >>> i didn't think about that, but i'm almost certain (almost!) you're right. >>> That's my understanding from having skipped over symlinks support in >>> libfossil so far. That means that symlinks support is not what you want >>> for >>> this purpose. Real symlinks to the files, but symlinks support explicitly >>> turned off, should serve the basic purpose - having the content of those >>> files in the repo. IIRC, if symlinks support is off, checking out the >>> repo >>> initially will create a file under the checkout dir with the contents of >>> the linked-to file. i think. >>> >>> -- >>> ----- stephan beal >>> http://wanderinghorse.net/home/stephan/ >>> http://gplus.to/sgbeal >>> "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of >>> those who insist on a perfect world, freedom will have to do." -- Bigby >>> Wolf >>> >>> _______________________________________________ >>> fossil-users mailing list >>> fossil-users@lists.fossil-scm.org >>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >>> >>> >>> >> >> > > -- > Using Opera's revolutionary email client: http://www.opera.com/mail/ > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
