On Fri, 09 May 2014 20:42:06 +0200, Stephan Beal <sgb...@googlemail.com>
wrote:
On Fri, May 9, 2014 at 8:33 PM, j. van den hoff
<veedeeh...@googlemail.com>wrote:
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.
FWIW, i've had to struggle with that question in libfossil and i
(currently) feel that the current behaviour follows the Principal of
Least
Surprise, in that it's consistent: no symlinks means no symlinks.
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.
Doesn't that mean that it supports both relative and absolute, and it's
up
to the user to choose which one he wants? There are use cases for both,
I agree. there is no "best choice" here.
IMO. (That said, i never was a big fan of having symlink support in
fossil!)
well, the possibility to do that symlink trick for tracking config files
all over the place
might be handy for some.
--
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
