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

[Richard Hipp]

Fossil version 1.34 has been tagged and binaries are now available on
the website (except for OpenBSD, which I cannot build at the moment
because devio.us is down, but probably anybody who uses OpenBSD can
run "./configure; make" against the tarball.)

So now would be a good time to hack away at a better implementation of symlinks.
-- 
D. Richard Hipp
d...@sqlite.org
___
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

[fossil-users] Symlinks issue, replacing a symlink with a directory breaks fossil update

[Matt Welland]

 (I posted this initially to the symlinks appear as regular files thread,
reposting as new thread).

Someone reported to me that there are problems when a symlink is replaced
with a directory or vice versa. Here is the script that he generated to
illustrate the issue:

## Create repo and initial population

fossil init bare.repo

mkdir link_target_dir
touch link_target_file
mkdir work1
cd work1
fossil open ../bare.repo
touch file
mkdir dir1
touch dir1/file1
ln -s ../link_target_file .
ln -s ../link_target_dir .
fossil add *
fossil commit -m add initial files .

## Clone repo
cd ..
mkdir work2
cd work2
fossil open ../bare.repo

## Change file types in repo
cd ../work1
echo Removing targets
fossil rm  dir1 file link_target_dir link_target_file
fossil commit -m remove all .
chmod -R 700 dir1 file link_target_dir link_target_file
rm -rf dir1 file link_target_dir link_target_file
echo Creating new targets swapping types
ln -s ../link_target_dir dir1
ln -s ../link_target_file file
mkdir link_target_dir
touch link_target_file
touch link_target_dir/file2
echo Adding to fossil
fossil add *
echo Commiting
fossil commit -m switch all types .

## Attempt pull in clone
cd ../work2

## At this command Fossil fails because it cannot swap the directory dir1
for the link that was created in it's place
fossil update
exit

-- 
Matt
-=-
90% of the nations wealth is held by 2% of the people. Bummer to be in the
majority...
___
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

[Eric Rubin-Smith]

Any plan to support symlinks any time soon?
___
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

[Stephan Beal]

On Thu, Aug 28, 2014 at 4:51 PM, Eric Rubin-Smith eas@gmail.com wrote:

 Any plan to support symlinks any time soon?


???

[stephan@host:~]$ f help set | grep -C3 sym
   access-log   If enabled, record successful and failed login attempts
in the accesslog table.  Default: off

   allow-symlinks   If enabled, don't follow symlinks, and instead treat
(versionable)   them as symlinks on Unix. Has no effect on Windows
(existing links in repository created on Unix become
plain-text files with link destination path inside).
Default: off



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

[Eric Rubin-Smith]

On Thu, Aug 28, 2014 at 10:55 AM, Stephan Beal sgb...@googlemail.com
wrote:


 On Thu, Aug 28, 2014 at 4:51 PM, Eric Rubin-Smith eas@gmail.com
 wrote:

 Any plan to support symlinks any time soon?


 ???

 [stephan@host:~]$ f help set | grep -C3 sym
access-log   If enabled, record successful and failed login attempts
 in the accesslog table.  Default: off

allow-symlinks   If enabled, don't follow symlinks, and instead treat
 (versionable)   them as symlinks on Unix. Has no effect on Windows
 (existing links in repository created on Unix become
 plain-text files with link destination path inside).
 Default: off



D'oh.  I had searched the forum + google and found threads in which the
devs described why there was no support, and then tested to see if there
was support by just checking in a symlink (which didn't work by default).
So I missed the existence of the feature.  Sorry for the noise! :-(

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

[Richard Hipp]

On Thu, Aug 28, 2014 at 11:03 AM, Eric Rubin-Smith eas@gmail.com
wrote:



 D'oh.  I had searched the forum + google and found threads in which the
 devs described why there was no support, and then tested to see if there
 was support by just checking in a symlink (which didn't work by default).
 So I missed the existence of the feature.  Sorry for the noise! :-(


Not noise.  This is signal that means we need to improve the
documentation

-- 
D. Richard Hipp
d...@sqlite.org
___
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

[Stephan Beal]

On Thu, Aug 28, 2014 at 5:04 PM, Richard Hipp d...@sqlite.org wrote:

 Not noise.  This is signal that means we need to improve the
 documentation


@Eric: feel free to suggest docs and where you think they belong.
Tomorrow's a half-day for me, so i could get them in tomorrow evening if
you're quick ;).


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

[Scott Robison]

On Thu, Aug 28, 2014 at 9:04 AM, Richard Hipp d...@sqlite.org wrote:

 D'oh.  I had searched the forum + google and found threads in which the
 devs described why there was no support, and then tested to see if there
 was support by just checking in a symlink (which didn't work by default).
 So I missed the existence of the feature.  Sorry for the noise! :-(


 Not noise.  This is signal that means we need to improve the
 documentation


Would there be any interest in adding symlink support to Windows (where
available [Vista  later], leaving the text file approach where it is not)?

-- 
Scott Robison
___
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

[Richard Hipp]

On Thu, Aug 28, 2014 at 11:23 AM, Scott Robison sc...@casaderobison.com
wrote:

 On Thu, Aug 28, 2014 at 9:04 AM, Richard Hipp d...@sqlite.org wrote:

  D'oh.  I had searched the forum + google and found threads in which the
 devs described why there was no support, and then tested to see if there
 was support by just checking in a symlink (which didn't work by default).
 So I missed the existence of the feature.  Sorry for the noise! :-(


 Not noise.  This is signal that means we need to improve the
 documentation


 Would there be any interest in adding symlink support to Windows (where
 available [Vista  later], leaving the text file approach where it is not)?


Did you just volunteer to submit patches?


-- 
D. Richard Hipp
d...@sqlite.org
___
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

[Stephan Beal]

On Thu, Aug 28, 2014 at 5:03 PM, Eric Rubin-Smith eas@gmail.com wrote:

 D'oh.  I had searched the forum + google and found threads in which the
 devs described why there was no support, and then tested to see if there
 was support by just checking in a symlink (which didn't work by default).
 So I missed the existence of the feature.  Sorry for the noise! :-(


One notable caveat which might save you some trouble: if you're trying to
save /etc, or similar, you're going to have to write wrapper scripts, as
fossil does not support any permissions except the +x bit, does it know
about any users except your own, and some files have strict requirements
regarding permissions (/etc/shadow, ~/.ssh/id_ida, etc.). Fossil is not the
right tool, by itself, for such uses of symlinks.

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

[Scott Robison]

On Thu, Aug 28, 2014 at 9:26 AM, Richard Hipp d...@sqlite.org wrote:




 On Thu, Aug 28, 2014 at 11:23 AM, Scott Robison sc...@casaderobison.com
 wrote:

 On Thu, Aug 28, 2014 at 9:04 AM, Richard Hipp d...@sqlite.org wrote:

  D'oh.  I had searched the forum + google and found threads in which
 the devs described why there was no support, and then tested to see if
 there was support by just checking in a symlink (which didn't work by
 default).  So I missed the existence of the feature.  Sorry for the noise!
 :-(


 Not noise.  This is signal that means we need to improve the
 documentation


 Would there be any interest in adding symlink support to Windows (where
 available [Vista  later], leaving the text file approach where it is not)?


 Did you just volunteer to submit patches?


 --
 D. Richard Hipp
 d...@sqlite.org

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




-- 
Scott Robison
___
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

[Scott Robison]

On Thu, Aug 28, 2014 at 9:26 AM, Richard Hipp d...@sqlite.org wrote:

 On Thu, Aug 28, 2014 at 11:23 AM, Scott Robison sc...@casaderobison.com
 wrote:

 On Thu, Aug 28, 2014 at 9:04 AM, Richard Hipp d...@sqlite.org wrote:

  D'oh.  I had searched the forum + google and found threads in which
 the devs described why there was no support, and then tested to see if
 there was support by just checking in a symlink (which didn't work by
 default).  So I missed the existence of the feature.  Sorry for the noise!
 :-(


 Not noise.  This is signal that means we need to improve the
 documentation


 Would there be any interest in adding symlink support to Windows (where
 available [Vista  later], leaving the text file approach where it is not)?


 Did you just volunteer to submit patches?


That was my idea (unless mentioning it motivated a dev to do it and commit
in 15 minutes or less, as often seems to happen around here). :)

-- 
Scott Robison
___
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

[Stephan Beal]

On Thu, Aug 28, 2014 at 5:35 PM, Scott Robison sc...@casaderobison.com
wrote:

 That was my idea (unless mentioning it motivated a dev to do it and commit
 in 15 minutes or less, as often seems to happen around here). :)


Oh, Scott, have you not learned? You haven't offered us any cookies yet ;).

(BTW: Windows isn't my thing, so i'm not offering! ;)

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

[Ron W]

On Thu, Aug 28, 2014 at 11:35 AM, Scott Robison sc...@casaderobison.com
wrote:

 That was my idea (unless mentioning it motivated a dev to do it and commit
 in 15 minutes or less, as often seems to happen around here). :)


It would be nice.

I used to be one of the people, here, trying to encourage symlink support
on MS Windows (because my team works in a mixed environment), but having
lived with the lack of symlinks on MS Win more than long enough for my team
and I to have a mostly smoothly running cross-platform build system that
doesn't use symlinks. It got down to a matter of naming conventions and
specifying the appropriate search paths in our make files. If nothing else,
it does (implicitly) document the inter project relationships better than
symlinks do.

So, if it's not too hard or time consuming to implement, I'm sure at least
some people, here, will use the feature. (Probably including me, despite
what I said above)
___
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

[Warren Young]

On 8/28/2014 09:23, Scott Robison wrote:


Would there be any interest in adding symlink support to Windows (where
available [Vista  later], leaving the text file approach where it is not)?


While Windows Vista+ technically can make symlinks on NTFS, it has 
restrictions that make it unworkable for Fossil:


1. If you aren't running as a member of the Administrators group, you 
cannot create symlinks, at all, ever.


2. If you *are* running as an Administrator user, you can't create 
symlinks from a process that isn't Run as Administrator.  (The 
exception is when logged into the actual Administrator account on a 
Server version of Windows, where all command shells are elevated.)


3. If your program is running as a Windows service (which Fossil can't 
do yet, but may one day be able to) it can't call this function at all, 
regardless of permission.  Only programs running under the interactive 
desktop can create symlinks.


Reference: http://goo.gl/ZXouH0

If you want symlinks on Windows, use Cygwin.  It emulates symlinks in a 
way that works on all versions of Windows that will run Cygwin, in a 
POSIXy way.


Cygwin actually has two symlink emulation mechanisms, one with better 
POSIX semantics but which only works among Cygwin programs, and another 
that emulates symlinks in terms of Windows LNK files, which works with 
all Windows programs:


http://cygwin.com/cygwin-ug-net/using-cygwinenv.html

And yes, Fossil is in the Cygwin package repository.
___
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

[Thomas Schnurrenberger]

On 28.08.2014 20:01, Warren Young wrote:

3. If your program is running as a Windows service (which Fossil can't
do yet, but may one day be able to) it can't call this function at all,
regardless of permission.  Only programs running under the interactive
desktop can create symlinks.


Fossil can be run as a Windows service. Please take a look at the
'winsrv' command. Obviously, this command exists only in Fossil
for Windows.

--
tsbg

___
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

[Ron W]

On Thu, Aug 28, 2014 at 2:01 PM, Warren Young war...@etr-usa.com wrote:

 While Windows Vista+ technically can make symlinks on NTFS, it has
 restrictions that make it unworkable for Fossil:

 1. If you aren't running as a member of the Administrators group, you
 cannot create symlinks, at all, ever.


At least in my development environment, some of the specialized tools we
use already require this for them to run.

Other SW dev environments are likely more restrictive. Non-DW-dev workers
almost certainly wont have this.


 2. If you *are* running as an Administrator user, you can't create
 symlinks from a process that isn't Run as Administrator.  (The exception
 is when logged into the actual Administrator account on a Server version of
 Windows, where all command shells are elevated.)


If issue #1 is resolved in a given user's environment, then this could be
workable. In general, I dislike running with admin priv for anything but
admin tasks.

I wonder if it would make sense for Fossil to spawn a separate program to
create symlinks.


 3. If your program is running as a Windows service (which Fossil can't do
 yet, but may one day be able to) it can't call this function at all,
 regardless of permission.  Only programs running under the interactive
 desktop can create symlinks.


This should not be a problem as only the Fossil CLI would be creating
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

[Warren Young]

On 8/28/2014 13:34, Thomas Schnurrenberger wrote:

Fossil can be run as a Windows service.


Thanks for the tip!

 Please take a look at the 'winsrv' command.

Alas, I do not keep a native Windows binary of fossil.exe on my Windows 
boxes.  As you can guess from my prior message, I only run Fossil under 
Cygwin, and Cygwin Fossil doesn't include the winsrv command.  I'm not 
sure there is a good reason for that to be the case, since a Cygwin 
program can still use native Win32 APIs.  On the other hand, Cygwin has 
its own run as service mechanism:


http://cygwin.wikia.com/wiki/Cygrunsrv

I found a doc bug, probably related to the ifdef that I imagine exists 
around this command's implementation:


http://fossil-scm.org/index.html/help/winsrv
___
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

[Warren Young]

On 8/28/2014 14:32, Ron W wrote:

On Thu, Aug 28, 2014 at 2:01 PM, Warren Young war...@etr-usa.com
mailto:war...@etr-usa.com wrote:

2. If you *are* running as an Administrator user, you can't create
symlinks from a process that isn't Run as Administrator.

If issue #1 is resolved in a given user's environment, then this could
be workable. In general, I dislike running with admin priv for anything
but admin tasks.


There's a fair bit more friction in to getting to a privileged shell on 
Windows than on POSIX systems, where all you need is a sudo or su -c 
command prefix.


Windows 8 made this a bit easier with its new Windows-X menu, but you 
still have to cd back to where you want to run the Fossil command, 
unless you choose to run under the elevated shell all the time.


You would have to run Fossil in such shell just to do a checkout of a 
repo containing a symlink, or an update on such a repo whenever the 
symlink changed.  Ugh.


Those wanting to play with this in advance of code appearing in Fossil 
can play with the mklink command, which only exists in the dreadful 
cmd.exe shell.  (It's a shell built-in, not a separate executable.)


Beware: the order of arguments to mklink is backwards relative to ln(1)!

Microsoft hasn't bothered adding that command to PowerShell.  The 
workarounds look pretty gnarly:


http://goo.gl/kdciMA

There's also a third Cygwin symlink mode, native mode:

https://cygwin.com/cygwin-ug-net/using.html#pathnames-symlinks


I wonder if it would make sense for Fossil to spawn a separate program
to create symlinks.


You'd need a Windows equivalent of setuid root.  I imagine if such a 
thing exists, it involves poking around inside the group policy editor 
or the user managment MMC snap-in.  If so, it may be even harder to 
enable on non-Pro or Server versions of Windows.


That separate program could be cmd.exe /c mklink..., but that would 
mean making cmd.exe elevated by default, which is a security hole big 
enough to float the Queen Mary through.  And if there is a separate 
program, that kicks the legs out from under Fossil's everything in one 
binary value proposition.



Only programs running
under the interactive desktop can create symlinks.

This should not be a problem as only the Fossil CLI would be creating
symlinks.


Yes, true.  Simply checking a new or changed symlink into a fossil 
winsrv instance should not require special permission.

___
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

[Ron W]

On Thu, Aug 28, 2014 at 5:35 PM, Warren Young war...@etr-usa.com wrote:

 On 8/28/2014 14:32, Ron W wrote:

 I wonder if it would make sense for Fossil to spawn a separate program
 to create symlinks.


 You'd need a Windows equivalent of setuid root.  I imagine if such a thing
 exists, it involves poking around inside the group policy editor or the
 user managment MMC snap-in.  If so, it may be even harder to enable on
 non-Pro or Server versions of Windows.


Right now, I have Win7 Pro available. In that, on the Compatibility tab of
the Properties of an EXE file, at the bottom, there is a checkbox Run as
Administrator. (or something like that - we use this to run some of our
specialized tools under MS Win)
___
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 to directories are traversed by fossil extras?

[Dmitry Chestnykh]

Matt,

There's symlinks branch that does what you want
http://www.fossil-scm.org/index.html/timeline?r=symlinks

Though I haven't merged the latest Fossil changes into it yet.

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

--
Dmitry Chestnykh

On Mar 11, 2011, at 5:30 AM, Matt Welland wrote:

 What is the plan for handling symlinks for fossil? My preference would
 be for fossil to treat links as a file. Storing the pointer would be
 great. Just ignoring links would also be fine by me. But actually
 traversing the links is not a good idea IMHO and is a real fossil
 killer. It is also not easy to work around.
 
 Links are commonly used to point to large amounts of static data
 outside of a build area or to reference one piece of data in multiple
 places. In neither of these cases would I want my scm tool to traverse
 the links and add the data. A setting ignore-links would be an ok
 compromise.
 
 Just my $0.02, thanks!


___
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 to directories are traversed by fossil extras?

[Matt Welland]

What is the plan for handling symlinks for fossil? My preference would
be for fossil to treat links as a file. Storing the pointer would be
great. Just ignoring links would also be fine by me. But actually
traversing the links is not a good idea IMHO and is a real fossil
killer. It is also not easy to work around.

Links are commonly used to point to large amounts of static data
outside of a build area or to reference one piece of data in multiple
places. In neither of these cases would I want my scm tool to traverse
the links and add the data. A setting ignore-links would be an ok
compromise.

Just my $0.02, thanks!
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users