On Thu, Sep 11, 2014 at 11:05 PM, Philip Bennefall
wrote:
> Ah, sweet. To be safe I am going to enable foreign key constraints before
> I do it, as well. If I do mess something up in the process, e.g. there is
> in fact some reference to that user somewhere even though I doubt it, how
> likely i
On Thu, Sep 11, 2014 at 10:02 PM, Ron W wrote:
> No different than my TH1 code being my responsibility to make sure it
> handles my custom fields correctly.
>
"handles" is the operative word. TH1 can _handle_ things, and JSON, by
itself, cannot.
> The only expectations of the JSON API would be
On 12 Sep 2014, at 5:06 am, org.fossil-scm.fossil-us...@io7m.com wrote:
> 'Lo.
>
> The fossil build scripts seem to be unable to find openssl on FreeBSD
> 9.2. It has a choice of the version included with the base system
> (in /usr) or the version available from FreeBSD ports (/usr/local),
> but
I see this is essentially a duplicate of this bug:
http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg11051.html
which was reported about 18 months ago, with a patch.
On Thu, Sep 11, 2014 at 3:18 PM, Colin McCormack wrote:
> (sorry for the funky formatting, Mailman)
>
> I wrote:
>
(sorry for the funky formatting, Mailman)
I wrote:
> I would expect, having started a server with basename (say)
> http://localhost/fossil to be able to proxy URLs of the form 'GET
> /fossil/logo ...' and have fossil strip the /fossil prefix (ie: basename)
> from the URL, and respond with the log
On 11 September 2014 13:50, Andy Bradford
wrote:
> Actually, it does work. The problem isn't with the versionable setting.
> There is a bug, but its in fossil open, not the setting.
>
> After you open the fossil, delete the link (which is actually now a
> file) and then do fossil update. It
org.fossil-scm.fossil-us...@io7m.com wrote:
> Think that may be partly wrong, as that'd mean that if I specified /usr,
> then the following would have to exist:
>
> /usr/openssl/ssl.h
Yeah, my mistake. The configurator does this (from auto.def):
set cflags "-I$dir/include"
set ldflags "-
Ah, sweet. To be safe I am going to enable foreign key constraints
before I do it, as well. If I do mess something up in the process, e.g.
there is in fact some reference to that user somewhere even though I
doubt it, how likely is Fossil to detect this and complain?
Kind regards,
Philip Benn
On Thu, Sep 11, 2014 at 4:21 PM, Philip Bennefall
wrote:
> I know that this goes against the philosophy of Fossil, and I realize that
> I am entering "dirty hack" territory. Nevertheless, I am wondering how I
> can remove a user that has made no commits, no ticket updates/additions,
> and no wiki
On 2014-09-11T16:09:42 -0400
Eric Rubin-Smith wrote:
>
> I skimmed through the configure code. Looks like you need to have
> the subdir and file 'openssl/ssl.h' beneath the dir you specify, and
> the subdir and files 'lib/libssl.so' and 'lib/libcrypto.so' beneath the
> dir you specify. Furth
I know that this goes against the philosophy of Fossil, and I realize
that I am entering "dirty hack" territory. Nevertheless, I am wondering
how I can remove a user that has made no commits, no ticket
updates/additions, and no wiki updates/additions whatsoever. Is it
enough to say:
delete fr
org.fossil-scm.fossil-us...@io7m.com wrote:
> 'Lo.
>
> The fossil build scripts seem to be unable to find openssl on FreeBSD
> 9.2. It has a choice of the version included with the base system
> (in /usr) or the version available from FreeBSD ports (/usr/local),
> but it can't seem to find either
On Thu, Sep 11, 2014 at 1:14 PM, Stephan Beal wrote:
> On Thu, Sep 11, 2014 at 7:03 PM, Ron W wrote:
>
>> As best I can determine, Fossil already demands that whomever adds custom
>> fields take responsibility for the customized New Ticket, View Tick and
>> Edit Ticket pages and associated TH1 a
On Thu, Sep 11, 2014 at 2:55 PM, Colin McCormack wrote:
> Hi,
>
> I would expect, having started a server with basename (say)
> http://localhost/fossil to be able to proxy URLs of the form 'GET
> /fossil/logo ...' and have fossil strip the /fossil prefix (ie: basename)
> from the URL, and respond
'Lo.
The fossil build scripts seem to be unable to find openssl on FreeBSD
9.2. It has a choice of the version included with the base system
(in /usr) or the version available from FreeBSD ports (/usr/local),
but it can't seem to find either of them.
Is there any way to get it to give more inform
Hi,
I would expect, having started a server with basename (say)
http://localhost/fossil to be able to proxy URLs of the form 'GET
/fossil/logo ...' and have fossil strip the /fossil prefix (ie: basename)
from the URL, and respond with the logo.
I understand that --basename modifies the links gene
On Thu, Sep 11, 2014 at 12:18 PM, Richard Hipp wrote:
> (Unless you can mount a pre-image attack against SHA1 - let's assume that
> is impossible.)
>
FYI, FWIW, SHA1 seems to be deprecated. There was a summary on slashdot.org
about Google planning to change Chrome's default setting for SHA1 warn
On Thu, Sep 11, 2014 at 12:09 PM, Nico Williams
wrote:
> On Thu, Sep 11, 2014 at 11:01 AM, Richard Hipp wrote:
> > On Thu, Sep 11, 2014 at 11:50 AM, Nico Williams
> > wrote:
> >>
> >> On Wed, Sep 10, 2014 at 10:47 PM, Richard Hipp
> >> > On the few cases when this has happened to me, I've move
Thus said David Mason on Thu, 11 Sep 2014 10:14:02 -0400:
> committing .fossil-settings/allow-symlinks first doesn't. This looks
> like a bug to me... what is the point of version-able allow-symlinks?
Actually, it does work. The problem isn't with the versionable setting.
There is a bug, but i
On Thu, Sep 11, 2014 at 7:03 PM, Ron W wrote:
> As best I can determine, Fossil already demands that whomever adds custom
> fields take responsibility for the customized New Ticket, View Tick and
> Edit Ticket pages and associated TH1 apply the semantics correctly and
> consistently.
>
But the J
On Wed, Sep 10, 2014 at 1:23 PM, Stephan Beal wrote:
> On Wed, Sep 10, 2014 at 7:04 PM, Ron W wrote:
>
>> Is it not possible to define an open-ended list of name-value pairs?
>>
>
> Sure we can, but then we've got a data format nobody can predict, which
> doesn't sit well with me (at the API lev
On Thu, Sep 11, 2014 at 6:33 PM, Nico Williams
wrote:
> On Thu, Sep 11, 2014 at 11:19 AM, Stephan Beal
> wrote:
> > No, he can't. Well, he can, but he will break the hashes of other
> records,
> > so any tamping will be noticed. Specifically, the Z- and R-cards detect
> any
> > sort of tampering
On Thu, Sep 11, 2014 at 11:19 AM, Stephan Beal wrote:
> No, he can't. Well, he can, but he will break the hashes of other records,
> so any tamping will be noticed. Specifically, the Z- and R-cards detect any
> sort of tampering.
Right. He can. If you've not pushed the commits anywhere else bef
On Thu, Sep 11, 2014 at 11:18 AM, Richard Hipp wrote:
> On Thu, Sep 11, 2014 at 12:07 PM, Nico Williams
> wrote:
>> Nothing can really be made immutable, but you can detect mutation.
>
> No. Version 9491ba7d738528f168657adb43a198238abde19e (the SQLite 3.8.6
> release) cannot be modified in any w
On Thu, Sep 11, 2014 at 6:07 PM, Nico Williams
wrote:
> not if the attacker controls it and the present. An attacker can
> always edit the history directly via SQLite3 access to the repo.
No, he can't. Well, he can, but he will break the hashes of other records,
so any tamping will be noticed.
On Thu, Sep 11, 2014 at 12:07 PM, Nico Williams
wrote:
>
> Nothing can really be made immutable, but you can detect mutation.
>
No. Version 9491ba7d738528f168657adb43a198238abde19e (the SQLite 3.8.6
release) cannot be modified in any way without changing its hash value,
thus making it something
On Thu, Sep 11, 2014 at 11:01 AM, Richard Hipp wrote:
> On Thu, Sep 11, 2014 at 11:50 AM, Nico Williams
> wrote:
>>
>> On Wed, Sep 10, 2014 at 10:47 PM, Richard Hipp
>> > On the few cases when this has happened to me, I've moved "goof" into a
>> > new
>> > branch (typically "mistake") then cherr
On Thu, Sep 11, 2014 at 10:18 AM, John Long wrote:
> On Sat, Sep 06, 2014 at 06:05:33PM -0600, Scott Robison wrote:
>> On Sat, Sep 6, 2014 at 5:24 PM, Nico Williams wrote:
>>
>> > > git branch -D name
>> >
>> > Eh, filesystems let you delete files. Unlike most filesystems, git lets
>> > you rest
On Thu, Sep 11, 2014 at 11:50 AM, Nico Williams
wrote:
> On Wed, Sep 10, 2014 at 10:47 PM, Richard Hipp
> > On the few cases when this has happened to me, I've moved "goof" into a
> new
> > branch (typically "mistake") then cherry pick the follow-on check-ins
> back
> > over to trunk, assuming t
On Wed, Sep 10, 2014 at 10:47 PM, Richard Hipp wrote:
> On Wed, Sep 10, 2014 at 10:48 PM, Matt Welland wrote:
>> On Wed, Sep 10, 2014 at 5:12 PM, Richard Hipp wrote:
>>> Sometimes we will make a check-in to trunk then later decide it doesn't
>>> belong there, so then move it into a branch. (
>>
On Sat, Sep 06, 2014 at 06:05:33PM -0600, Scott Robison wrote:
> On Sat, Sep 6, 2014 at 5:24 PM, Nico Williams wrote:
>
> > > git branch -D name
> >
> > Eh, filesystems let you delete files. Unlike most filesystems, git lets
> > you restore your deleted branches (yes, provided you don't gc the r
On 11 September 2014 01:06, Andy Bradford
wrote:
> Thus said David Mason on Thu, 11 Sep 2014 00:42:09 -0400:
>
>> : Daves-MacBook-Retina-784 ; cat .fossil-settings/allow-symlinks
>> yes
>> : Daves-MacBook-Retina-784 ; fs ci -m test
>> New_Version: 240dcb9a36ff5fde1c3bc1ae1e906dbb479b3698
>
> I cou
Well, it looks like i have to round trip through git anyhow, as a lot
of the repos created by direct "bzr fast-export | fossil import" come
up empty past the initial commit. Curious and curiouser.
On 10 September 2014 17:47, Richard Hipp wrote:
>
>
> On Wed, Sep 10, 2014 at 11:38 AM, Dömötör Guly
33 matches
Mail list logo
