On 4/9/2015 12:00 PM, David Mason wrote:
> I use symlinks a lot. I *really* wish fossil handled them "properly".
>
> This is one of my biggest beefs about fossil.
Fossil's driving requirement is to support the development of SQLite,
and its applicability anywhere else is just a bonus. Since SQL
Thanks for the examples, Andy.
I use symlinks a lot. I *really* wish fossil handled them "properly".
This is one of my biggest beefs about fossil.
The other big one is that if I set some property (in this case
allow-symlinks true) and I also set the corresponding .fossil-setting I get
a warning
On 4/8/2015 2:44 PM, David Mason wrote:
> Here is another problem with symlinks:
>
> [add files in a subdirectory]
> [commit]
> [move subdirectory outside of repository]
> [create symlink to subdirectory with same name as original]
> [Fossil doesn't notice anything happened]
> Same problem if you
What Scott says, abbreviated from the C FAQ:
http://c-faq.com/null/ptrtest.html
FWIW, I always use if(p) to verify a pointer is valid.
../Dave
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mai
Here is another problem with symlinks:
Last login: Tue Apr 7 20:11:50 on ttys004
: ~ ; cd /tmp
: /tmp ; fs init foo.fossil
project-id: d24564a4337e8c50f77a20ee355e2f76a9b84b78
server-id: aa025469a22046732337b7fa075c7c4e85f45c0a
admin-user: dmason (initial password is "d5a283")
: /tmp ; cd
On Wed, Apr 8, 2015 at 12:17 PM, Ron W wrote:
> On Wed, Apr 8, 2015 at 1:58 PM, Scott Robison
> wrote:
>
>> Or whatever your team dictates. :)
>>
>
> In our case, we are required to follow "industry guidelines", except where
> compelling technical issues require a deviation. And such deviations
On Wed, Apr 8, 2015 at 1:58 PM, Scott Robison
wrote:
> Or whatever your team dictates. :)
>
In our case, we are required to follow "industry guidelines", except where
compelling technical issues require a deviation. And such deviations must
be documented. Also, use of NULL is considered more ind
On Wed, Apr 8, 2015 at 11:13 AM, Ron W wrote:
> FWIW, the coding rules I work under require us to write
> "if(pointer!=NULL)" because the invalid pointer is a compiler-dependent
> value.
>
> I've actually used a compiler where NULL was not 0. Instead it was
> 0x. Presumably this was parti
On Wed, Apr 8, 2015 at 12:25 PM, Andy Goth wrote:
> I hesitated to do much more than move existing code around since I don't
> know how strong the stylistic preferences are. For example, one thing I
> wanted to do was treat pointers as booleans, e.g. "if(pointer)" rather than
> "if(pointer!=0)",
On 4/8/15, Andy Goth wrote:
> On 4/8/2015 1:33 AM, bch wrote:
>> I don't know if it's just me, or if there's a school of thought
>> regarding this, but if this is a case of maintaining symlinks to publish
>> as part of a distribution, I usually relegate their management to a
>> script that will be
(email to reporter of problem several years ago, copying list so
discussion can continue here)
I made a fix to Fossil opening a repository containing symlinks. It's
currently on a branch. For details, see this thread:
http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg20112.ht
On 4/8/2015 1:14 AM, Joe Mistachkin wrote:
I've made some tweaks on the branch.
Thank you, I appreciate it. I hesitated to do much more than move
existing code around since I don't know how strong the stylistic
preferences are. For example, one thing I wanted to do was treat
pointers as bo
On 4/8/2015 1:33 AM, bch wrote:
I don't know if it's just me, or if there's a school of thought
regarding this, but if this is a case of maintaining symlinks to publish
as part of a distribution, I usually relegate their management to a
script that will be part of a release generation process (wi
I don't know if it's just me, or if there's a school of thought regarding
this, but if this is a case of maintaining symlinks to publish as part of a
distribution, I usually relegate their management to a script that will be
part of a release generation process (with "repository != release" in
mind
Andy Goth wrote:
>
> My andygoth-versioned-open branch (just checked in) addresses this
> problem and seems to fix the symlink issue. However, the Fossil coding
> style is rather alien to me, particularly the way it leaks memory on
> purpose, so the way I'm doing things may not be the best. Ple
On 4/8/2015 12:15 AM, Andy Goth wrote:
> My naïve user expectation is checking in .fossil-settings/allow-symlinks
> with contents "1" is all I need to do to get symlinks to work in a
> Fossil repository. It does make it possible to check in symlinks.
> However, it doesn't help when opening a new c
My naïve user expectation is checking in .fossil-settings/allow-symlinks
with contents "1" is all I need to do to get symlinks to work in a
Fossil repository. It does make it possible to check in symlinks.
However, it doesn't help when opening a new checkout. In this
situation, symlinks are creat
17 matches
Mail list logo
