Re: [fossil-users] symlinks (was Re: xkcd on git)

[tonyp]

Although I certainly agree with your point (and don’t care about symlinks 
myself, BTW), I’m afraid it’s a bit too late to expect portability of repos 
between platforms (mainly, Linux and Windows) without prior care from the repo 
maintainers.

Just the fact the Linux has case-sensitive filenames, and Windows does not, can 
make it impossible for a Linux repo to check-out in Windows correctly (if the 
Linux repo has two or more files in the same subdirectory that differ only in 
case).
From: Stephan Beal 
Sent: Thursday, November 05, 2015 9:18 AM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] symlinks (was Re: xkcd on git)

On Tue, Nov 3, 2015 at 7:59 PM, David Mason <dma...@ryerson.ca> wrote:


  It's simple: a symlink is a filesystem artifact and should be reflected as 
such in the repository.  It should not be followed; if foo is a symlink and I 
say "fs add foo/bar" it should probably give an error. (This might surprise 
people the first time, but it's easy to explain - foo/bar isn't part of the 
repo, regardless of where foo points.)


But it's not quite that simple, philosophically speaking: we expect Fossil to 
extract _exactly_ what we put in it, and that's not portably possible when it 
comes to symlinks. As soon as someone checks out your repo on a non-Unix 
system, fossil is creating output which you did not put in fossil. That's a 
tremendous psychological/philosophical hurdle for me. i'd rather live without 
symlinks than know that my repos check out differently depending on the 
platform.

-- 

- 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
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] symlinks (was Re: xkcd on git)

[Joan Picanyol i Puig]

* Stephan Beal  [20151105 08:09]:
> On Tue, Nov 3, 2015 at 7:59 PM, David Mason  wrote:
> 
> >
> > It's simple: a symlink is a filesystem artifact and should be reflected as
> > such in the repository.  It should not be followed; if foo is a symlink and
> > I say "fs add foo/bar" it should probably give an error. (This might
> > surprise people the first time, but it's easy to explain - foo/bar isn't
> > part of the repo, regardless of where foo points.)
> >
> 
> But it's not quite that simple, philosophically speaking: we expect Fossil
> to extract _exactly_ what we put in it, and that's not portably possible
> when it comes to symlinks. As soon as someone checks out your repo on a
> non-Unix system, fossil is creating output which you did not put in fossil.
> That's a tremendous psychological/philosophical hurdle for me. i'd rather
> live without symlinks than know that my repos check out differently
> depending on the platform.

Then request for a setting the precludes checking symlinks in.

qvb
--
pica
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] symlinks (was Re: xkcd on git)

[Rafal Bisingier]

Hi,

On 2015-11-05 at 08:18 CET
Stephan Beal  wrote:

>On Tue, Nov 3, 2015 at 7:59 PM, David Mason  wrote:
>
>> It's simple: a symlink is a filesystem artifact and should be reflected as
>> such in the repository.  It should not be followed; if foo is a symlink and
>> I say "fs add foo/bar" it should probably give an error. (This might
>> surprise people the first time, but it's easy to explain - foo/bar isn't
>> part of the repo, regardless of where foo points.)
>
>But it's not quite that simple, philosophically speaking: we expect Fossil
>to extract _exactly_ what we put in it, and that's not portably possible
>when it comes to symlinks. As soon as someone checks out your repo on a
>non-Unix system, fossil is creating output which you did not put in fossil.
>That's a tremendous psychological/philosophical hurdle for me. i'd rather
>live without symlinks than know that my repos check out differently
>depending on the platform.

Thank God there's no DOS port of fossil, or we would end with 8.3
filenames... ;-)

Symlinks are sometimes crucial _on_ _unix_, and not supporting them,
only because of the existence of Windows port, would be very bad
choice. For me it would be better to not have Windows port than symlinks
support. Thankfully for others, I'm not a developer ;-)

-- 
Greetings
Rafal Bisingier
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] symlinks (was Re: xkcd on git)

[Warren Young]

On Nov 4, 2015, at 11:52 PM, Stephan Beal wrote:
> 
> You've hit it right on the head: POLICY. No SCM should enforce 
> project-specific policies, and symlinks (for me) fall into that category.

I can argue the reverse on the same basis: Fossil shouldn’t be making a policy 
decision about what I put into my repository, just because it might not work on 
some other platform that I’m not using.

You may say that I might later want to check the repo out on that other 
platform, but the consequences here really are not that dire.  If you check a 
symlink into the repo, and some future Windows native symlink feature is added 
to Fossil, and you can’t use it because $REASON, you can fix it in trunk on a 
POSIX box and try again.

All you’ve lost is the ability to check old versions of the code out on that 
platform.

Yes, that means you can’t do things like bisect against old versions, but 
clearly if you’re using symlinks, you’ve got platforms around that will let you 
do the bisection.  And you probably don’t have a platform-specific bug to 
bisect in this case, since you clearly weren’t checking the repo out on Windows 
back when the symlink was added.

War story: I use Adobe Lightroom quite a lot.  (Which is based on SQLite, by 
the way!)  A couple of versions ago, it stopped letting me name folders with a 
trailing dot,[*] which is perfectly legal on OS X, but illegal on Windows.  I 
don’t use Lightroom on Windows, but Adobe doesn’t let me use a feature of my OS 
because I *might* someday want to move that catalog to Windows.

The result is that Lightroom now enforces an LCD policy on file names, refusing 
the union of the restrictions of Windows and OS X on both platforms.  So, 
trailing dots aren’t the only annoying restriction.  The inability to use 
colons is another, for example.

I don’t want to be mollycoddled.


[*] If you’re wondering why I might want to use a trailing dot on folder names, 
I sometimes abbreviate people’s last names, when the initial is all I need to 
disambiguate the name.  I want to call the folder “Stephan B.”, not “Stephan B”.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] symlinks (was Re: xkcd on git)

[Eric Rubin-Smith]

On Thu, Nov 5, 2015 at 1:56 AM, Stephan Beal  wrote:
>
> Thanks to Joe for stepping in to stop the bikeshedding :).
>

Yeah.  In that spirit, I will abstain from addressing your other points
from this morning, since I think most of the useful arguments are already
on the table.

Instead I'll just hope that you realize the depth of your error before the
next time the topic comes back up. :-)

Eric
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] symlinks (was Re: xkcd on git)

[Stephan Beal]

On Thu, Nov 5, 2015 at 5:07 PM, Eric Rubin-Smith  wrote:

> On Thu, Nov 5, 2015 at 1:56 AM, Stephan Beal 
> wrote:
>>
>> Thanks to Joe for stepping in to stop the bikeshedding :).
>>
>
> Yeah.  In that spirit, I will abstain from addressing your other points
> from this morning, since I think most of the useful arguments are already
> on the table.
>
> Instead I'll just hope that you realize the depth of your error before the
> next time the topic comes back up. :-)
>

i've learned my lesson - the next time i keep my (immutable!) minority
opinions to myself! ;)

-- 
- 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

Re: [fossil-users] symlinks (was Re: xkcd on git)

[Stephan Beal]

On Thu, Nov 5, 2015 at 7:52 AM, Stephan Beal  wrote:

> You've hit it right on the head: POLICY. No SCM should enforce
> project-specific policies, and symlinks (for me) fall into that category.
>

And next time i'll finish reading the new thread posts before replying.
Thanks to Joe for stepping in to stop the bikeshedding :).

-- 
- 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

Re: [fossil-users] symlinks (was Re: xkcd on git)

[Stephan Beal]

On Tue, Nov 3, 2015 at 4:48 PM, Eric Rubin-Smith  wrote:

>
> On Tue, Nov 3, 2015 at 1:33 AM, Stephan Beal 
> wrote:
>
>>
>> Absolute paths in an SCM are "just plain wrong" (IMO). Even the innocuous
>> link to /etc might be wrong in certain build environments (and won't work
>> on Windows). Why should fossil assist in doing the wrong thing?
>>
>
> Here you give away the game by saying "IMO".  Whether it's wrong is a
> question of policy, as you seem to admit.  And such examples have clearly
> led you down a path of arguing that your policy is the right one -- to the
> detriment of the tool.
>

You've hit it right on the head: POLICY. No SCM should enforce
project-specific policies, and symlinks (for me) fall into that category.


> Your particular example is actually great for my case, because it applies
> with equal force to the case of filesystems.  A filesystem can be mounted
> at any mount point, so an absolute symlink to '/etc' that works fine when
> the FS is mounted at '/' will not be correct when the FS is mounted at
> '/foo/bar'.  So absolute symlinks are also wrong in this case.  Why should
> Linux assist in doing the wrong thing?
>

The OS is there to make anything possible. An SCM is there to track source
code (which, by long-standing convention, exists in one tree). That's
comparing one fruit with another fruit (sorry, but a certain luxury
hardware vendor has ruined the more conventional phrasing of that for me).


>
>> Stated yet another way: we don't expect the SCM to solve all problems
>>> that users create.
>>>
>>
>> But if it sets out to solve them, then it should solve them, not provide
>> a half-solution to philosophically unsolvable problems. (IMO.)
>>
>
> Your argument is analogous to an argument that compilers can't detect and
> correct all program bugs, so we may as well not write compilers at all.
> This is an enormous problem, you could argue, because almost all programs
> have bugs, and so the compiler is doomed to fail almost every time!
>

Again, fruit and other fruit. An SCM has a very specific target, whereas a
compiler is there to make _anything_ possible.


> We can support symlinks without setting out to solve all problems that
> arise.  It's not a half-solution -- it's a full solution to a narrower
> (and, in fact, pretty simple) problem.
>

If it were that simple, it likely would have been done to the majority's
satisfaction by now ;).


> It defaults to off, and it should go without saying that a "do the right
> thing" setting should default to on.
>

i disagree - "off" is the most platform-compatible option. i want all of my
source trees to check out identically on all platforms, and that cannot
happen if i've got a symlink in there. (That said, i _thought_ it defaulted
to "on" for Unix platforms.)

My thoughts on symlinks in SCMs can be summarized accurately in 3 words:
"can of worms."

-- 
- 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

Re: [fossil-users] symlinks (was Re: xkcd on git)

[Stephan Beal]

On Tue, Nov 3, 2015 at 7:59 PM, David Mason  wrote:

>
> It's simple: a symlink is a filesystem artifact and should be reflected as
> such in the repository.  It should not be followed; if foo is a symlink and
> I say "fs add foo/bar" it should probably give an error. (This might
> surprise people the first time, but it's easy to explain - foo/bar isn't
> part of the repo, regardless of where foo points.)
>

But it's not quite that simple, philosophically speaking: we expect Fossil
to extract _exactly_ what we put in it, and that's not portably possible
when it comes to symlinks. As soon as someone checks out your repo on a
non-Unix system, fossil is creating output which you did not put in fossil.
That's a tremendous psychological/philosophical hurdle for me. i'd rather
live without symlinks than know that my repos check out differently
depending on the platform.

-- 
- 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

Re: [fossil-users] symlinks (was Re: xkcd on git)

[Eric Rubin-Smith]

>
> This issue was more subtle than it originally appeared.  I think the
> current
> trunk
> changes should make it work right for both versioned and non-versioned
> allow-symlinks
> settings.


Thanks so much for looking at that.  I was trying to get started writing
some unit test cases around this so I could submit them back here.  I note
that 69 tests fail in version [2186f0f0e7] (see below).  Though it seems
pretty unlikely (from their names) that your symlink changes caused this.

* End of utf: 69 errors so far **
* Final result: 69 errors out of 27300 tests
* Failures: amend-comment-5.1 amend-comment-5.2 amend-comment-5.3
amend-comment-5.4 clean-6 clean-12 clean-18 relative-tree-name-100.1
relative-tree-name-100.2 relative-tree-name-100.3 relative-tree-name-100.4
relative-tree-name-101.1 relative-tree-name-101.2 relative-tree-name-101.3
relative-tree-name-102.1 relative-tree-name-102.2 relative-tree-name-102.3
relative-tree-name-103.1 absolute-tree-name-100.1 absolute-tree-name-100.2
absolute-tree-name-100.3 absolute-tree-name-100.4 absolute-tree-name-101.1
absolute-tree-name-101.2 absolute-tree-name-101.3 absolute-tree-name-102.1
absolute-tree-name-102.2 absolute-tree-name-102.3 absolute-tree-name-103.1
merge-utf-27-23 merge-utf-27-32 merge_multi-4 merge_renames-5
mv-soft-relative-2 mv-soft-relative-4 mv-hard-relative-2 mv-hard-relative-4
mv-soft-absolute-2 mv-soft-absolute-4 mv-hard-absolute-2 mv-hard-absolute-4
rm-soft-relative-4 rm-soft-relative-6 rm-hard-relative-4 rm-hard-relative-6
rm-soft-absolute-4 rm-soft-absolute-6 rm-hard-absolute-4 rm-hard-absolute-6
revert-1-1 revert-1-2 revert-1-3 revert-1-4 revert-1-5 revert-1-6
revert-1-7 revert-2-1 th1-checkout-1 th1-checkout-2 th1-header-2
th1-footer-2 th1-footer-3 th1-artifact-3 th1-artifact-5 th1-artifact-7
th1-artifact-9 th1-globalState-1 th1-globalState-8 th1-encode64-3

In any case, the three scenarios I am personally aware of behave as
expected now.  Thanks again!

For completeness, Warren Young seems to be complaining about Fossil's path
resolution logic when symlinks are present.  This is (from my perspective)
a very different issue, but you nevertheless may want to track it.  Also, I
did not read every detail in the thread ("xkcd on git") that led to this
subtopic, so perhaps people aired other symlink-related complaints there.

Eric
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] symlinks (was Re: xkcd on git)

[Andy Bradford]

Thus said Eric Rubin-Smith on Wed, 04 Nov 2015 10:01:10 -0500:

> * Failures: amend-comment-5.1 amend-comment-5.2 amend-comment-5.3
> amend-comment-5.4

These are  unaffected. If you  were to  enable -verbose mode  they would
probably  indicate that  you're missing  ed (necessary  for testing  the
interactive edit of a comment).  I ran the suite and it runs fine:

* End of amend: 0 errors so far **
* Final result: 0 errors out of 123 tests

Andy
-- 
TAI64 timestamp: 4000563a2855


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] symlinks (was Re: xkcd on git)

[Rich Neswold]

On Tue, Nov 3, 2015 at 12:33 AM, Stephan Beal  wrote:
> On Mon, Nov 2, 2015 at 6:32 PM, Eric Rubin-Smith  wrote:
>> A user who only ever uses fossil on unix should get unix symlink semantics
>> on unix, without quirks or surprises.  Surely you and DRH would agree with
>> that?
>
> i can't speak for Richard, but if i had my way, fossil wouldn't support
> symlinks at all. They are inherently platform-dependent and, IMHO, belong in
> the build process, not the SCM. They are a big can of worms, as we can see
> by large amount of emails on the topic. To be clear: i use symlinks all over
> the place on my systems, i just refuse to use them in an SCM. Call me old
> fashioned.

When this discussion started (many messages ago), I shared Mr
Rubin-Smith's opinion. but as arguments were presented, I'm now
leaning towards Mr. Beal's. We're arguing how much file system
semantics should 'fossil' manage? The more you manage, the tougher it
gets to be cross-platform.

How much of the spectrum should fossil track:

- Files. This is a no-brainer; the whole purpose is to track changing
file contents.
- Directories. Also a no-brainer; all serious file systems have a way
to organize files into directory trees (although I guess this means
fossil won't run on CPM machines) and directories are a very useful
way to organize a project's files.
- Permissions. As a fossil user, I haven't been tripped up by
incorrect permissions, so I don't know if it saves Unix permissions or
not. Whatever it's doing, it seems correct in a Unix-like environment.
- Symlinks. Now we're getting into file system specifics. Some users
may want to track them because they find them useful. What about users
that find FIFOs or block devices or character device useful? Should
fossil attempt to save enough information to recreate them?
- Extended attributes. Many file systems now have extended attributes.
Should Mac users complain because fossil doesn't support HFS+ extended
attributes or resource forks?

I think fossil can support the permissions level. Anything further
down in the previous list should be part of the project's build cycle.

--
Rich
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] symlinks (was Re: xkcd on git)

[Eric Rubin-Smith]

On Tue, Nov 3, 2015 at 1:33 AM, Stephan Beal  wrote:

>
> On Mon, Nov 2, 2015 at 6:32 PM, Eric Rubin-Smith 
> wrote:
>
>> the user when trying to move a tarball from one OS to another.  In other
>> words, I believe that you perceive a dichotomy that is false (between (a)
>> not implementing symlinks at all and (b) implementing them while having
>> fossil perfectly and automatically solve all complications that may arise).
>>
>
> That sounds like a fair summary of my feelings on SCM support for
> symlinks, but i'd argue that if a system (SCM) cannot do (b) for the vast
> majority of use cases, then it probably shouldn't be implemented at all.
> Why not? Because it's the _displeased_ users who complain the loudest when
> something doesn't work how they want/expect it do, and that percentage of
> users is relatively high in the case of symlinks.
>
> A user who only ever uses fossil on unix should get unix symlink semantics
>> on unix, without quirks or surprises.  Surely you and DRH would agree with
>> that?
>>
>
> i can't speak for Richard, but if i had my way, fossil wouldn't support
> symlinks at all. They are inherently platform-dependent and, IMHO, belong
> in the build process, not the SCM. They are a big can of worms, as we can
> see by large amount of emails on the topic. To be clear: i use symlinks all
> over the place on my systems, i just refuse to use them in an SCM. Call me
> old fashioned.
>
>

:-) Fossil creates a problem by not supporting symlinks properly, and you
use the volume of complaints about the problem to support your claim that
the problem was inevitable.

Not implementing them at all, or implementing them poorly as Fossil has, is
what maximizes complaints -- hence the large amount of emails.  I wouldn't
dream of complaining about Git's support of symlinks, because it just works.

I just don't think this is a deep conundrum.  Lots of cross-platform
programs have to deal with symlinks, have done so, and the universe has not
collapsed from the logical implications.  If the link is broken just fix
it.  If the OS doesn't support symlinks then those see some reasonable
degradation, possibly coupled with warnings.  And those of us who use OSes
with symlink support don't have to suffer needlessly because of the poor
decision-making of other OS authors.


>
> Absolute paths in an SCM are "just plain wrong" (IMO). Even the innocuous
> link to /etc might be wrong in certain build environments (and won't work
> on Windows). Why should fossil assist in doing the wrong thing?
>

Here you give away the game by saying "IMO".  Whether it's wrong is a
question of policy, as you seem to admit.  And such examples have clearly
led you down a path of arguing that your policy is the right one -- to the
detriment of the tool.

Your particular example is actually great for my case, because it applies
with equal force to the case of filesystems.  A filesystem can be mounted
at any mount point, so an absolute symlink to '/etc' that works fine when
the FS is mounted at '/' will not be correct when the FS is mounted at
'/foo/bar'.  So absolute symlinks are also wrong in this case.  Why should
Linux assist in doing the wrong thing?

Well, because it's a really useful tool.  Sometimes the tool can be misused
or uncover some corner cases or whatever, but overall it's really useful.
So let's support it and let the user deal with those weird cases if they
come up (or just wallow in the pure bliss of a useful tool if the cases
don't come up).


> Stated yet another way: we don't expect the SCM to solve all problems that
>> users create.
>>
>
> But if it sets out to solve them, then it should solve them, not provide a
> half-solution to philosophically unsolvable problems. (IMO.)
>

Your argument is analogous to an argument that compilers can't detect and
correct all program bugs, so we may as well not write compilers at all.
This is an enormous problem, you could argue, because almost all programs
have bugs, and so the compiler is doomed to fail almost every time!

Of course you wouldn't say that, because you would rightly notice that this
is a false dichotomy: it's not the compiler's job to detect all program
bugs.

We can support symlinks without setting out to solve all problems that
arise.  It's not a half-solution -- it's a full solution to a narrower
(and, in fact, pretty simple) problem.


>
> For context, my particular use case: we need the openssl source tree in
>> our project, and that tree contains internal symlinks.  Again, people have
>> to jump through silly hoops to get new repos set up properly, because
>> fossil breaks those symlinks by populating new repos with flat text files
>> (and this goes undiscovered til the openssl build fails in mysterious
>> ways).
>>
>
> To the best of my knowledge, if symlinks are enabled in the fossil config,
> it will DTRT with them (to the best of its ability). i haven't tried it,
> but that's my understanding of the feature. 

Re: [fossil-users] symlinks (was Re: xkcd on git)

[Eric Rubin-Smith]

>
>
> Just to clarify, what are the behavioral changes needed on the Unix side to
> make
> things work seamlessly?
>

(1) Default allow-symlinks to true
(2) Fix bug in which the allow-symlinks setting is not honored while
opening a repository (requires manual clean-up of symlinks after opening a
repo).  I pasted a transcript session a few emails ago -- let me know if
you would like me to re-paste.  I also submitted a patch to this forum
something like a year ago and then detected a bug with it -- let me know if
you would like me to also re-raise that.


> Are there differing opinions on the changes needed (i.e. and not just
> whether or not there should be any changes in the current behavior)?
>

So far this thread has not reached such a stage, afaik.

Eric
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] symlinks (was Re: xkcd on git)

[Matt Welland]

On Tue, Nov 3, 2015 at 9:40 AM, Eric Rubin-Smith  wrote:

>
> - Symlinks. Now we're getting into file system specifics. Some users
>> may want to track them because they find them useful. What about users
>> that find FIFOs or block devices or character device useful? Should
>> fossil attempt to save enough information to recreate them?
>>
>
> Support for FIFOs and block devices is a separate discussion.  My defense
> of symlink support does not force me to also defend FIFO and block device
> support.
>

+1

- Extended attributes. Many file systems now have extended attributes.
>> Should Mac users complain because fossil doesn't support HFS+ extended
>> attributes or resource forks?
>>
>
> They may do so if they think it's reasonable, and be subject to all the
> usual considerations around developers' time and attention, etc.  But
> again, for the purposes of arguing whether good symlink support is
> warranted, that is a separate topic.
>

+1


>
> > I think fossil can support the permissions level. Anything further
> > down in the previous list should be part of the project's build cycle.
>
> My biggest complaint about this discussion is that some folks seem to be
> coming at it like fossil is the first tool to confront this issue.  It
> isn't.  There are real examples of programs in the wild (SCMs, no less!)
> that have solved it in ways that are more coherent, more user-friendly, and
> just as easy to implement as what fossil already has.  For Git, our
> poster-child for difficult tools, this is just a total non-issue.
>

+1


> Fossil already sort-of attempts to do what Git does, it just has some bugs
> and incorrect default config values.  So the distance to fixing Fossil is
> quite small.  But closing the gap (and keeping it closed) is much harder
> when a vocal subset of the community argues that supporting symlinks is
> impossible or ill-advised (it is neither, by my lights).
>

I think the Mark Twain quote; “I've lived through some terrible things in
my life, some of which actually happened.” applies here. The objections to
better symlink support are based on imaginings that may or may not ever
eventuate.

There is a simple bottom line that might help. If the developers of fossil
wish to eliminate a large swath of current and potential users then leave
symlink support as is or remove it entirely. Understand that this support
is not really optional for many of us. For me (and I think for others) this
is not a philosophical discussion. This is a pragmatic discussion.


> Eric
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] symlinks (was Re: xkcd on git)

[David Mason]

On 3 November 2015 at 10:48, Eric Rubin-Smith  wrote:

>
> On Tue, Nov 3, 2015 at 1:33 AM, Stephan Beal 
> wrote:
>>
>> i can't speak for Richard, but if i had my way, fossil wouldn't support
>> symlinks at all.
>>
>
This would force me to stop using Fossil (or at least updating to a version
that didn't support them), and to recommend to everyone (including the
hundreds of students who I've introduced to Fossil) to be wary using it.

Part of the problem in this discussion is that everyone seems to be
assuming that Fossil is only used for source trees and makefiles.  I
maintain a dozen web sites, a few of them are my course-based ones.  I have
(simplified for expository purposes) let's say 3 repos: Courses, cps710 and
cps506.  Courses has sub-directories Themes (for CSS, etc.) and JScript.
 cps710 and cps506 are nested under Courses, so the structure looks like:
Courses
   Themes
   JScript
   cps710
 Themes -> ../Themes
 JScript -> ../JScript
 f2013
  index.html
  f2013 -> .
  current -> ../current
  Themes -> ../Themes
  JScript -> ../JScript
 f2015
  index.html
  f2015 -> .
  current -> ../current
  Themes -> ../Themes
  JScript -> ../JScript
 current -> f2015
 index.html -> current/index.html
   cps506
 Themes -> ../Themes
  JScript -> ../JScript
 index.html -> current/index.html
etc.

So symlinks, with nested repos is a huge win for me.  Fortunately, I only
need to set up a new course occasionally, so I only have to fight with
Fossil about symlinks occasionally, but too often!

The poor support for symlinks is far and away my biggest complaint with
Fossil. (The limited support for file permissions is second, because I
often want to put things in the repo that I'm not ready to show the
students yet.)

It's simple: a symlink is a filesystem artifact and should be reflected as
such in the repository.  It should not be followed; if foo is a symlink and
I say "fs add foo/bar" it should probably give an error. (This might
surprise people the first time, but it's easy to explain - foo/bar isn't
part of the repo, regardless of where foo points.)


> :-) Fossil creates a problem by not supporting symlinks properly, and you
> use the volume of complaints about the problem to support your claim that
> the problem was inevitable.
>
> Not implementing them at all, or implementing them poorly as Fossil has,
> is what maximizes complaints -- hence the large amount of emails.
>

Exactly.  Please fix symlinks so that if you live only on Unix you get
seamless support.  If you work back and forth between Windows and Unix then
you probably just don't use symlinks, so it won't be a problem for you!

../Dave
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] symlinks (was Re: xkcd on git)

[Joe Mistachkin]

David Mason wrote:
>
> Exactly.  Please fix symlinks so that if you live only on Unix you get
seamless
> support.  If you work back and forth between Windows and Unix then you
probably
> just don't use symlinks, so it won't be a problem for you! 
>

To All:

Just to clarify, what are the behavioral changes needed on the Unix side to
make
things work seamlessly?

Are there differing opinions on the changes needed (i.e. and not just
whether or
not there should be any changes in the current behavior)?

--
Joe Mistachkin

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] symlinks (was Re: xkcd on git)

[Joe Mistachkin]

Eric Rubin-Smith wrote:
>
> (1) Default allow-symlinks to true
> (2) Fix bug in which the allow-symlinks setting is not honored while
> opening a repository
>

Please try the latest Fossil trunk and let us know if that fixes all the
issues you were seeing.

--
Joe Mistachkin

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] symlinks (was Re: xkcd on git)

[Warren Young]

On Nov 3, 2015, at 2:51 PM, Joe Mistachkin  wrote:
> 
> Please try the latest Fossil trunk and let us know if that fixes all the
> issues you were seeing.

Version c985d905c6 still fails the test case I posted here yesterday:

  http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg21786.html

Distilled, that post says that if allow-symlinks is enabled, and dereferencing 
a link names a file that is in the Fossil-managed tree, it should behave as if 
you had typed the managed file name instead of the symlink alias to it.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] symlinks (was Re: xkcd on git)

[Eric Rubin-Smith]

On Tue, Nov 3, 2015 at 4:51 PM, Joe Mistachkin 
wrote:

>
> Eric Rubin-Smith wrote:
> >
> > (1) Default allow-symlinks to true
> > (2) Fix bug in which the allow-symlinks setting is not honored while
> > opening a repository
> >
>
> Please try the latest Fossil trunk and let us know if that fixes all the
> issues you were seeing.
>
>
Version [aa92270fe9] seems to have regressed the case of opening a
repository with a .fossil-checkout/allow-symlinks file set to 'on'.  See
the transcript below.  Note that I had created the repository earlier (I
assume this does not matter for the purposes of this test).

[little:test] $ fossil version
This is fossil version 1.34 [aa92270fe9] 2015-11-03 22:09:23 UTC
[little:test] $ fossil set
access-log
admin-log
allow-symlinks
auto-captcha
{snip}
[little:test] $ mkdir sandbox
[little:test] $ cd sandbox/
[little:sandbox] $ fossil open ../foo.db
.fossil-settings/allow-symlinks
foo
foo.lnk
project-name: 
repository:   /home/eas/tmp/test/sandbox/../foo.db
local-root:   /home/eas/tmp/test/sandbox/
config-db:/home/eas/.fossil
project-code: 430c12926d87d5e8e5517f89d786fbd1a5dde989
checkout: 727acad4494a443864efdf56bef74fbdc3787fef 2015-11-03 19:49:14
UTC
parent:   389a88be2cef9727974da9ecc30d10d3df1bae79 2015-11-03 19:48:58
UTC
tags: trunk
comment:  Add files. (user: eas)
check-ins:3
[little:sandbox] $ lh
total 24K
-rw-r--r-- 1 eas eas 3 Nov  3 17:59 foo.lnk
-rw-r--r-- 1 eas eas 4 Nov  3 17:59 foo
[little:sandbox] $ rm -f foo.lnk
[little:sandbox] $ fossil update
UPDATE foo.lnk
---
updated-to:   727acad4494a443864efdf56bef74fbdc3787fef 2015-11-03 19:49:14
UTC
tags: trunk
comment:  Add files. (user: eas)
changes:  1 file modified.
 "fossil undo" is available to undo changes to the working checkout.
[little:sandbox] $ lh
total 16K
-rw-r--r-- 1 eas eas 4 Nov  3 17:59 foo
lrwxrwxrwx 1 eas eas 3 Nov  3 17:59 foo.lnk -> foo
[little:sandbox] $ cat .fossil-settings/allow-symlinks
on
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] symlinks (was Re: xkcd on git)

[Eric Rubin-Smith]

On Tue, Nov 3, 2015 at 2:44 PM, Joe Mistachkin 
wrote:

>
> Eric Rubin-Smith wrote:
> >
> > (2) Fix bug in which the allow-symlinks setting is not honored while
> > opening a repository
> >
>
> Did the following changes (a while back) not address this?
>
> https://www.fossil-scm.org/fossil/vinfo/010451e7a5fe116a?sbs=0
>
> If not, in what way are they not adequate?


They seem to address the case where the setting is created via
.fossil-settings/allow-symlinks.  Very cool!

But the transcript I pasted uses a "global" setting because of the order in
which I issued the command for that test.  That global setting does not
seem to be honored on open, even in v1.34.

Eric
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] symlinks (was Re: xkcd on git)

[Joe Mistachkin]

Eric Rubin-Smith wrote:
>
> (2) Fix bug in which the allow-symlinks setting is not honored while
> opening a repository
>

Did the following changes (a while back) not address this?

https://www.fossil-scm.org/fossil/vinfo/010451e7a5fe116a?sbs=0

If not, in what way are they not adequate?

--
Joe Mistachkin

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] symlinks (was Re: xkcd on git)

[Joe Mistachkin]

Eric Rubin-Smith wrote:
>
> Version [aa92270fe9] seems to have regressed the case of opening a
repository with a
> .fossil-checkout/allow-symlinks file set to 'on'.  See the transcript
below.  Note
> that I had created the repository earlier (I assume this does not matter
for the
> purposes of this test).

This issue was more subtle than it originally appeared.  I think the current
trunk
changes should make it work right for both versioned and non-versioned
allow-symlinks
settings.

--
Joe Mistachkin

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] symlinks (was Re: xkcd on git)

[Graeme Pietersz]

I also find symlinks useful for similar reasons - although I do not use
nested repos, so my usage is simpler.

It does become a problem when I work with someone who uses Windows and 
can see that is harder to fix. Would it not be possible for Fossil to
detect whether the user can create symlinks or not, and then create a
symlink if possible? Perhaps add a Windows specific option to choose
between this and the current behaviour?


On 04/11/15 00:29, David Mason wrote:
> On 3 November 2015 at 10:48, Eric Rubin-Smith  > wrote:
>
>
> On Tue, Nov 3, 2015 at 1:33 AM, Stephan Beal
> > wrote:
>
> i can't speak for Richard, but if i had my way, fossil
> wouldn't support symlinks at all.
>
>
> This would force me to stop using Fossil (or at least updating to a
> version that didn't support them), and to recommend to everyone
> (including the hundreds of students who I've introduced to Fossil) to
> be wary using it.
>
> Part of the problem in this discussion is that everyone seems to be
> assuming that Fossil is only used for source trees and makefiles.  I
> maintain a dozen web sites, a few of them are my course-based ones.  I
> have (simplified for expository purposes) let's say 3 repos: Courses,
> cps710 and cps506.  Courses has sub-directories Themes (for CSS, etc.)
> and JScript.  cps710 and cps506 are nested under Courses, so the
> structure looks like:
> Courses
>Themes
>JScript
>cps710
>  Themes -> ../Themes
>  JScript -> ../JScript
>  f2013
>   index.html
>   f2013 -> .
>   current -> ../current
>   Themes -> ../Themes
>   JScript -> ../JScript
>  f2015
>   index.html
>   f2015 -> .
>   current -> ../current
>   Themes -> ../Themes
>   JScript -> ../JScript
>  current -> f2015
>  index.html -> current/index.html
>cps506
>  Themes -> ../Themes
>   JScript -> ../JScript
>  index.html -> current/index.html
> etc.
>
> So symlinks, with nested repos is a huge win for me.  Fortunately, I
> only need to set up a new course occasionally, so I only have to fight
> with Fossil about symlinks occasionally, but too often!
>
> The poor support for symlinks is far and away my biggest complaint
> with Fossil. (The limited support for file permissions is second,
> because I often want to put things in the repo that I'm not ready to
> show the students yet.)
>
> It's simple: a symlink is a filesystem artifact and should be
> reflected as such in the repository.  It should not be followed; if
> foo is a symlink and I say "fs add foo/bar" it should probably give an
> error. (This might surprise people the first time, but it's easy to
> explain - foo/bar isn't part of the repo, regardless of where foo points.)
>  
>
> :-) Fossil creates a problem by not supporting symlinks properly,
> and you use the volume of complaints about the problem to support
> your claim that the problem was inevitable.
>
> Not implementing them at all, or implementing them poorly as
> Fossil has, is what maximizes complaints -- hence the large amount
> of emails.
>
>
> Exactly.  Please fix symlinks so that if you live only on Unix you get
> seamless support.  If you work back and forth between Windows and Unix
> then you probably just don't use symlinks, so it won't be a problem
> for you! 
>
> ../Dave
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

-- 
Graeme Pietersz
http://moneyterms.co.uk/
http://pietersz.net/

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] symlinks (was Re: xkcd on git)

[Eric Rubin-Smith]

> - Symlinks. Now we're getting into file system specifics. Some users
> may want to track them because they find them useful. What about users
> that find FIFOs or block devices or character device useful? Should
> fossil attempt to save enough information to recreate them?
>

Support for FIFOs and block devices is a separate discussion.  My defense
of symlink support does not force me to also defend FIFO and block device
support.


> - Extended attributes. Many file systems now have extended attributes.
> Should Mac users complain because fossil doesn't support HFS+ extended
> attributes or resource forks?
>

They may do so if they think it's reasonable, and be subject to all the
usual considerations around developers' time and attention, etc.  But
again, for the purposes of arguing whether good symlink support is
warranted, that is a separate topic.

> I think fossil can support the permissions level. Anything further
> down in the previous list should be part of the project's build cycle.

My biggest complaint about this discussion is that some folks seem to be
coming at it like fossil is the first tool to confront this issue.  It
isn't.  There are real examples of programs in the wild (SCMs, no less!)
that have solved it in ways that are more coherent, more user-friendly, and
just as easy to implement as what fossil already has.  For Git, our
poster-child for difficult tools, this is just a total non-issue.

Fossil already sort-of attempts to do what Git does, it just has some bugs
and incorrect default config values.  So the distance to fixing Fossil is
quite small.  But closing the gap (and keeping it closed) is much harder
when a vocal subset of the community argues that supporting symlinks is
impossible or ill-advised (it is neither, by my lights).

Eric
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] symlinks (was Re: xkcd on git)

[bch]

On Nov 2, 2015 9:32 AM, "Eric Rubin-Smith"  wrote:
>
>
 My problem is not the decision itself, but that, in terms of how
fossil should behave, it's a philosophical question. Those have no
right/wrong answer, and i dislike seeing software pretend to know the
answer to such questions.
>>>
>>>
>>> Isn't that essentially confirming my point? Fossil merely stores the
pointer. It need not waste time analysing the link to make a judgement call
in any way. Just store it and move on.
>>
>>
>> But if it only stores a pointer, and requires the user to reconstruct
the link, it's not terribly useful/friendly. The user would potentially
have to replace fossil's placeholder pseudosymlink file with a link of his
own (which he could point somewhere else than fossil thinks it "should"
be). He might has well simply have a "post-checkout" script which sets up
his symlinks for him. To me, that's the "proper"/"safest" way to handle
symlinks in a repo (but i'm willing to accept being in the minority on that
point).
>
>
> Fossil's poor handling of symlinks is a severe knock against it, both in
my opinion and in my experience with proselytizing it to people who are not
already on the fossil kool-aid.

Philosophically, I think of links as build artifacts, which are rarely
stored in an scm. I do avoid them as much as possible, but I've
occasionally wondered: does anybody manage the links as the build artifacts
of a script, and keep the script itself under version control?

So, if you need: foo -> bar, do this:

#!/bin/sh
ln -sf bar foo

... and store that script under VC?

> Every time a user opens our repo on unix, the symlinks are initially
populated as regular files whose contents are the link target.  This is
causes me significant embarrassment for recommending fossil when others on
my project have to deal with it.  (I tried pushing through a code patch a
year or so ago to fix this, but I detected some bug or another with it and
I don't think the devs ever accepted the patch (not sure).)
>
> Note that this a Fossil-specific quirk.  Not all cross-platform programs
are equally awkward in their symlink handling -- in fact, most are better.
>
> Stephan: I think that you are overcomplicating the matter, in the sense
that the complications you note can (and should) be passed on to the user
-- in the same way that the program tar(1) might pass on such complications
to the user when trying to move a tarball from one OS to another.  In other
words, I believe that you perceive a dichotomy that is false (between (a)
not implementing symlinks at all and (b) implementing them while having
fossil perfectly and automatically solve all complications that may arise).
>
> A user who only ever uses fossil on unix should get unix symlink
semantics on unix, without quirks or surprises.  Surely you and DRH would
agree with that?
>
> The cases you are worried about:
>
> * absolute paths -- fossil can preserve the absolute path, it's the
user's fault if that's the wrong thing to do.
> * broken links -- fossil preserves the original link, it's the user's
fault if the link is incorrectly broken.
> * cross-platform semantics -- implement the proper semantics where you
can, and don't where you can't.  A user who only ever uses fossil on unix
should get unix symlink semantics on unix.  If the fossil devs are able to
implement proper symlink handling on next year's Windows, then awesome.  If
not, then degrade to whatever and document it for the user (emitting
warning messages as appropriate or so on).
>
> Stated yet another way: we don't expect the SCM to solve all problems
that users create.  An example is naming branches incorrectly.  If the user
names a branch "" when the project has a rule that branch names should
be descriptive, we don't expect Fossil to flag it and deal with it -- we
expect the user's coworkers to yell at them til they fix it.  So it should
be with symlinks -- each project has its own rules, Fossil doesn't know
about those rules, Fossil just faithfully syncs the target around, and if a
link gets broken in violation of project rules then a user gets yelled at
by another user.  (Note that the project-local rules might be "never use
symlinks because our Windows doesn't handle them how we would like" or "we
think symlinks are always perverse".  Fossil should not IMO be constrained
by such subsets of the user base.)
>
> For context, my particular use case: we need the openssl source tree in
our project, and that tree contains internal symlinks.  Again, people have
to jump through silly hoops to get new repos set up properly, because
fossil breaks those symlinks by populating new repos with flat text files
(and this goes undiscovered til the openssl build fails in mysterious
ways).  So their first experience with Fossil winds up being a pretty big
"WTF".
>
> My $.02,
> Eric
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> 

Re: [fossil-users] symlinks (was Re: xkcd on git)

[Stephan Beal]

On Mon, Nov 2, 2015 at 6:32 PM, Eric Rubin-Smith  wrote:

> the user when trying to move a tarball from one OS to another.  In other
> words, I believe that you perceive a dichotomy that is false (between (a)
> not implementing symlinks at all and (b) implementing them while having
> fossil perfectly and automatically solve all complications that may arise).
>

That sounds like a fair summary of my feelings on SCM support for symlinks,
but i'd argue that if a system (SCM) cannot do (b) for the vast majority of
use cases, then it probably shouldn't be implemented at all. Why not?
Because it's the _displeased_ users who complain the loudest when something
doesn't work how they want/expect it do, and that percentage of users is
relatively high in the case of symlinks.

A user who only ever uses fossil on unix should get unix symlink semantics
> on unix, without quirks or surprises.  Surely you and DRH would agree with
> that?
>

i can't speak for Richard, but if i had my way, fossil wouldn't support
symlinks at all. They are inherently platform-dependent and, IMHO, belong
in the build process, not the SCM. They are a big can of worms, as we can
see by large amount of emails on the topic. To be clear: i use symlinks all
over the place on my systems, i just refuse to use them in an SCM. Call me
old fashioned.


> 
> * absolute paths -- fossil can preserve the absolute path, it's the user's
> fault if that's the wrong thing to do.
>

Absolute paths in an SCM are "just plain wrong" (IMO). Even the innocuous
link to /etc might be wrong in certain build environments (and won't work
on Windows). Why should fossil assist in doing the wrong thing?

Stated yet another way: we don't expect the SCM to solve all problems that
> users create.
>

But if it sets out to solve them, then it should solve them, not provide a
half-solution to philosophically unsolvable problems. (IMO.)


> For context, my particular use case: we need the openssl source tree in
> our project, and that tree contains internal symlinks.  Again, people have
> to jump through silly hoops to get new repos set up properly, because
> fossil breaks those symlinks by populating new repos with flat text files
> (and this goes undiscovered til the openssl build fails in mysterious
> ways).
>

To the best of my knowledge, if symlinks are enabled in the fossil config,
it will DTRT with them (to the best of its ability). i haven't tried it,
but that's my understanding of the feature. IIRC symlinks are on by default
on Unix systems and off everywhere else (that info might be outdated,
though).


-- 
- 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

[fossil-users] symlinks (was Re: xkcd on git)

[Eric Rubin-Smith]

> My problem is not the decision itself, but that, in terms of how fossil
>>> should behave, it's a philosophical question. Those have no right/wrong
>>> answer, and i dislike seeing software pretend to know the answer to such
>>> questions.
>>>
>>
>> Isn't that essentially confirming my point? Fossil merely stores the
>> pointer. It need not waste time analysing the link to make a judgement call
>> in any way. Just store it and move on.
>>
>
> But if it only stores a pointer, and requires the user to reconstruct the
> link, it's not terribly useful/friendly. The user would potentially have to
> replace fossil's placeholder pseudosymlink file with a link of his own
> (which he could point somewhere else than fossil thinks it "should" be). He
> might has well simply have a "post-checkout" script which sets up his
> symlinks for him. To me, that's the "proper"/"safest" way to handle
> symlinks in a repo (but i'm willing to accept being in the minority on that
> point).
>

Fossil's poor handling of symlinks is a severe knock against it, both in my
opinion and in my experience with proselytizing it to people who are not
already on the fossil kool-aid.

Every time a user opens our repo on unix, the symlinks are initially
populated as regular files whose contents are the link target.  This is
causes me significant embarrassment for recommending fossil when others on
my project have to deal with it.  (I tried pushing through a code patch a
year or so ago to fix this, but I detected some bug or another with it and
I don't think the devs ever accepted the patch (not sure).)

Note that this a Fossil-specific quirk.  Not all cross-platform programs
are equally awkward in their symlink handling -- in fact, most are better.

Stephan: I think that you are overcomplicating the matter, in the sense
that the complications you note can (and should) be passed on to the user
-- in the same way that the program tar(1) might pass on such complications
to the user when trying to move a tarball from one OS to another.  In other
words, I believe that you perceive a dichotomy that is false (between (a)
not implementing symlinks at all and (b) implementing them while having
fossil perfectly and automatically solve all complications that may arise).

A user who only ever uses fossil on unix should get unix symlink semantics
on unix, without quirks or surprises.  Surely you and DRH would agree with
that?

The cases you are worried about:

* absolute paths -- fossil can preserve the absolute path, it's the user's
fault if that's the wrong thing to do.
* broken links -- fossil preserves the original link, it's the user's fault
if the link is incorrectly broken.
* cross-platform semantics -- implement the proper semantics where you can,
and don't where you can't.  A user who only ever uses fossil on unix should
get unix symlink semantics on unix.  If the fossil devs are able to
implement proper symlink handling on next year's Windows, then awesome.  If
not, then degrade to whatever and document it for the user (emitting
warning messages as appropriate or so on).

Stated yet another way: we don't expect the SCM to solve all problems that
users create.  An example is naming branches incorrectly.  If the user
names a branch "" when the project has a rule that branch names should
be descriptive, we don't expect Fossil to flag it and deal with it -- we
expect the user's coworkers to yell at them til they fix it.  So it should
be with symlinks -- each project has its own rules, Fossil doesn't know
about those rules, Fossil just faithfully syncs the target around, and if a
link gets broken in violation of project rules then a user gets yelled at
by another user.  (Note that the project-local rules might be "never use
symlinks because our Windows doesn't handle them how we would like" or "we
think symlinks are always perverse".  Fossil should not IMO be constrained
by such subsets of the user base.)

For context, my particular use case: we need the openssl source tree in our
project, and that tree contains internal symlinks.  Again, people have to
jump through silly hoops to get new repos set up properly, because fossil
breaks those symlinks by populating new repos with flat text files (and
this goes undiscovered til the openssl build fails in mysterious ways).  So
their first experience with Fossil winds up being a pretty big "WTF".

My $.02,
Eric
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] symlinks (was Re: xkcd on git)

[bch]

On 11/2/15, Ron W  wrote:
> On Mon, Nov 2, 2015 at 1:16 PM, bch  wrote:
>>
>> Philosophically, I think of links as build artifacts, which are rarely
>> stored in an scm. I do avoid them as much as possible, but I've
>> occasionally wondered: does anybody manage the links as the build
>> artifacts
>> of a script, and keep the script itself under version control?
>>
> We used to, but now use the vpath directive in GNU make, so longer need
> symlinks.

After I posted this, I thought a Makefile (still to manage actual
symlinks) would be an improvement over a shell script; you're punting
on symlinks completely (using VPATH). How has VPATH (or the previous
shell script) treated you as a symlink manager/replacement ?

-bch


>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] symlinks (was Re: xkcd on git)

[Ron W]

On Mon, Nov 2, 2015 at 1:16 PM, bch  wrote:
>
> Philosophically, I think of links as build artifacts, which are rarely
> stored in an scm. I do avoid them as much as possible, but I've
> occasionally wondered: does anybody manage the links as the build artifacts
> of a script, and keep the script itself under version control?
>
We used to, but now use the vpath directive in GNU make, so longer need
symlinks.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] symlinks (was Re: xkcd on git)

[Ron W]

On Mon, Nov 2, 2015 at 6:00 PM, bch  wrote:
>
> After I posted this, I thought a Makefile (still to manage actual
> symlinks) would be an improvement over a shell script; you're punting
> on symlinks completely (using VPATH). How has VPATH (or the previous
> shell script) treated you as a symlink manager/replacement ?
>

It works fine.

Of course, we also had to tell the compiler/linker to search those same
directories.

Example:
vpath %.c $(VCPATH)
vpath %.h $(VHPATH)

CCOPTS += $(VHPATH:%=-I%)

And yes, before we started using vpath, we managed symlinks in our
makefiles.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users