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
