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

: 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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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

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

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

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

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

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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)