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 pu
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
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 h
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 shou
bject: 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"
* 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
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
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
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 sho
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
>
> 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 thi
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
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 thi
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 a
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
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
_
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/
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?
>
>
> 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
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 behaviora
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 d
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 sa
On Tue, Nov 3, 2015 at 10:40 AM, Eric Rubin-Smith wrote:
> 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.
I interpret the discussion as a more philosophical one. Should
symlinks be part of a project's c
> - 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 an
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 symlink
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
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 perfect
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 m
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
>
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 i
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
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.
>>>
>>>
>>>
> 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? Fos
(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
On Thu, Aug 28, 2014 at 5:35 PM, Warren Young 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
On 8/28/2014 14:32, Ron W wrote:
On Thu, Aug 28, 2014 at 2:01 PM, Warren Young 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 envir
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 Fossi
On Thu, Aug 28, 2014 at 2:01 PM, Warren Young 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 leas
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
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
On Thu, Aug 28, 2014 at 11:35 AM, Scott Robison
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
On Thu, Aug 28, 2014 at 5:35 PM, Scott Robison
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
On Thu, Aug 28, 2014 at 9:26 AM, Richard Hipp wrote:
> On Thu, Aug 28, 2014 at 11:23 AM, Scott Robison
> wrote:
>
>> On Thu, Aug 28, 2014 at 9:04 AM, Richard Hipp wrote:
>>>
>>> D'oh. I had searched the forum + google and found threads in which
the devs described why there was no support
On Thu, Aug 28, 2014 at 9:26 AM, Richard Hipp wrote:
>
>
>
> On Thu, Aug 28, 2014 at 11:23 AM, Scott Robison
> wrote:
>
>> On Thu, Aug 28, 2014 at 9:04 AM, Richard Hipp wrote:
>>>
>>> D'oh. I had searched the forum + google and found threads in which
the devs described why there was no s
On Thu, Aug 28, 2014 at 5:03 PM, Eric Rubin-Smith 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 t
On Thu, Aug 28, 2014 at 11:23 AM, Scott Robison
wrote:
> On Thu, Aug 28, 2014 at 9:04 AM, Richard Hipp 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 checki
On Thu, Aug 28, 2014 at 9:04 AM, Richard Hipp 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 t
On Thu, Aug 28, 2014 at 5:04 PM, Richard Hipp 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 ;).
On Thu, Aug 28, 2014 at 11:03 AM, Eric Rubin-Smith
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 mis
On Thu, Aug 28, 2014 at 5:03 PM, Eric Rubin-Smith 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 t
On Thu, Aug 28, 2014 at 10:55 AM, Stephan Beal
wrote:
>
> On Thu, Aug 28, 2014 at 4:51 PM, Eric Rubin-Smith
> 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 a
On Thu, Aug 28, 2014 at 4:51 PM, Eric Rubin-Smith 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
a
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
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
On Fri, March 11, 2011 4: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 go
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
56 matches
Mail list logo