+1.
Shunning a commit is a bad idea.
But fossil will not differentiate type of content when shunning so not sure if
it can prevent shunning a commit.
> - Original Message -
> From: Erlis Vidal
> Sent: 10/06/11 12:21 AM
> To: fossil-users@lists.fossil-scm.org
> Subject: Re: [fossil-users]
On Thu, 6 Oct 2011 11:17:06 -0400, Richard Hipp
wrote:
>Fossil is fairly strict about the format of filenames - to try to avoid
>cross-platform issues and globbing issues.
>http://www.fossil-scm.org/fossil/artifact/79bed8df57b?ln=425
Thanks for the tip.
__
On Thu, 6 Oct 2011 11:01:43 -0400, Tomek Kott
wrote:
> Yep, it should. It's worked for me for all of the repo's I've tried.
So I guess WinFossil doesn't work when the repo is opened at the root
of a partition that contains a lot of directories because it will go
through each one looking for files
On Thu, Oct 6, 2011 at 7:34 PM, Matt Welland wrote:
> Ah, cool!! I assumed the SQLITE error was somehow related to the
> non-writablitiy of the file.
BTW: the file was not updated because fossil bailed out because of the SQL
error. From a user's perspective, the SQL error might not have seemed
On Oct 6, 2011, at 19:49 , Matt Welland wrote:
> Hmmm I have 1.19 but still see the problem since I built from source
> before it was released? It might be a little clearer to ensure the 1.19 is
> only in the files from the checkin prior to the release.
>
> chlr11723> fossil version
> This
On Thu, Oct 6, 2011 at 7:34 PM, Matt Welland wrote:
> carefully and dig a little deeper next time so the feedback can be of
> higher quality.
LOL! That is quite possibly the best "please excuse me" i've ever seen
posted on a list. That one's of put-it-on-a-t-shirt quality. :)
--
- stephan
On Oct 6, 2011, at 19:03 , Matt Welland wrote:
> fossil: SQLITE_ERROR: near "redoflag": syntax error
> fossil: near "redoflag": syntax error
> UPDATE undo SET content=:c, existsflag=1, isExe=0, isLink=0 redoflag=NOT
> redoflag WHERE pathname='foo.txt'
Is this from later trunk version? I fixed th
Hmmm I have 1.19 but still see the problem since I built from source
before it was released? It might be a little clearer to ensure the 1.19 is
only in the files from the checkin prior to the release.
chlr11723> fossil version
This is fossil version 1.19 [24c16584cc] 2011-08-26 14:59:43 UTC
B
Ah, cool!! I assumed the SQLITE error was somehow related to the
non-writablitiy of the file. I'll read more carefully and dig a little
deeper next time so the feedback can be of higher quality.
On Thu, Oct 6, 2011 at 10:27 AM, Richard Hipp wrote:
>
>
> On Wed, Oct 5, 2011 at 4:16 PM, Matt Wella
On Wed, Oct 5, 2011 at 4:16 PM, Matt Welland wrote:
> Rolling back prior filesystem changes...
> UNDO foo.txt
> fossil: SQLITE_ERROR: near "redoflag": syntax error
> fossil: near "redoflag": syntax error
> UPDATE undo SET content=:c, existsflag=1, isExe=0, isLink=0 redoflag=NOT
> redoflag WHERE p
On Thu, Oct 6, 2011 at 7:21 PM, Stephan Beal wrote:
> what version are you using? The current code has a command between isLink=0
> redoflag...
>
command == comma, of course
--
- stephan beal
http://wanderinghorse.net/home/stephan/
___
fossil-use
On Thu, Oct 6, 2011 at 7:03 PM, Matt Welland wrote:
> UPDATE undo SET content=:c, existsflag=1, isExe=0, isLink=0 redoflag=NOT
> redoflag WHERE pathname='foo.txt'
>
what version are you using? The current code has a command between isLink=0
redoflag...
db_prepare(&q,
"UPDATE undo SET
On Thu, Oct 6, 2011 at 9:32 AM, Stephan Beal wrote:
> On Thu, Oct 6, 2011 at 6:28 PM, Matt Welland wrote:
>
>> Of course it is easy to fix. But why expose your users to all the
>> distracting and irrelevant junk in the error message? If possible report the
>> fact that the file can't be opened a
On Thu, 6 Oct 2011 18:20:12 +0200
Stephan Beal wrote:
> > Last time I checked GPB was implemented in the form of a C++
> > library.
> Many C++ APIs can be used from C code, actually, as long as their C+
> +-only functionality can be hidden behind an intermediary C-style API.
My point is that we'l
On Thu, Oct 6, 2011 at 6:28 PM, Matt Welland wrote:
> Of course it is easy to fix. But why expose your users to all the
> distracting and irrelevant junk in the error message? If possible report the
> fact that the file can't be opened and stop.
>
> The end user was confused by the message and re
On Thu, Oct 6, 2011 at 12:07 AM, Stephan Beal wrote:
> On Wed, Oct 5, 2011 at 11:20 PM, Matt Welland wrote:
>
>> "fossil: unable to open file "/tmp/mrwellan/testing/test/foo.txt" for
>> writing"
>>
>> The remainder of the message confused the developer (and me for that
>> matter).
>>
>>
> chmod
On Thu, Oct 6, 2011 at 6:20 PM, Stephan Beal wrote:
> Diffs and whatnot are a whole other problem altogether, because there are
> no clients other than fossil itself which handles fossil-format diffs.
>
That's not true - fossil interacts with many graphical diff programs.
> So those are also w
On Thu, Oct 6, 2011 at 5:59 PM, Konstantin Khomoutov <
flatw...@users.sourceforge.net> wrote:
> Last time I checked GPB was implemented in the form of a C++ library.
>
Many C++ APIs can be used from C code, actually, as long as their C++-only
functionality can be hidden behind an intermediary C-s
On Thu, 6 Oct 2011 11:31:16 -0400
Erlis Vidal wrote:
> Take a look to protocol buffers. The implementation is not restricted
> only to java, c++, python. Other people are adding more languages...
> this gives you kind of "portability"
Last time I checked GPB was implemented in the form of a C++
On Thu, Oct 06, 2011 at 04:18:27PM +0100, Jacek Cała wrote:
> Is this too much hassle to improve the exec in this matter? As said
> @Stephan, I think that this option is much more viable than using any
> intermediaries like standard output/error, protocol buffers or JSON
> API. What do you think? I
2011/10/6 Jacek Cała
> Agree, however, I thought that JSON API was the solution for linking
>
Well, it's "a" solution, not "the" solution. But it's "the" only solution
for the time being ;).
> external apps to fossil, and hence having ability to call fossil
> directly would make the API redund
Take a look to protocol buffers. The implementation is not restricted only
to java, c++, python. Other people are adding more languages... this gives
you kind of "portability"
-Erlis
On Thu, Oct 6, 2011 at 11:19 AM, Stephan Beal wrote:
> On Thu, Oct 6, 2011 at 4:47 PM, Erlis Vidal wrote:
>
>>
On Thu, Oct 6, 2011 at 4:47 PM, Erlis Vidal wrote:
> Do you know about "protocol buffers". I'm asking because I didn't know
> about them since recently.
>
>
> http://google-opensource.blogspot.com/2008/07/protocol-buffers-googles-data.html
>
Never heard of them. Thanks for the link :).
> Could
Is this too much hassle to improve the exec in this matter? As said
@Stephan, I think that this option is much more viable than using any
intermediaries like standard output/error, protocol buffers or JSON
API. What do you think? I could spent a bit of my time and look at it
if this is doable and a
On Thu, Oct 6, 2011 at 11:11 AM, Stephan Beal wrote:
> On Thu, Oct 6, 2011 at 4:30 PM, Tomek Kott wrote:
>
>> As for the illegal characters, I guess I haven't ran across that one. You
>> should probably submit a bug for that one with Ingo. Fossil itself allows
>> that kind of name, right?
>>
>
>
2011/10/6 Stephan Beal :
> 2011/10/6 Jacek Cała
>>
>> A quick look on wikipedia and PE format
>> (http://en.wikipedia.org/wiki/Portable_Executable) shows that PE is
>> somewhat related to a unix COFF format. Perhaps the same trick is
>> possible on *nix platforms. I think that it would solve a lot
On Thu, Oct 6, 2011 at 4:30 PM, Tomek Kott wrote:
> As for the illegal characters, I guess I haven't ran across that one. You
> should probably submit a bug for that one with Ingo. Fossil itself allows
> that kind of name, right?
>
i'm fairly certain (but not entirely) that that error comes from
2011/10/6 Jacek Cała
> I've just made a simple test executable Prog1.exe that links to
> another executable Prog2.exe. You can run Prog2.exe normally (it has
> it's own main function), but also you can link to it and use the
> functions it exports. My Prog1.exe uses a test function from
> Prog2.e
On Oct 6, 2011, at 16:59 , Jacek Cała wrote:
> I've just realized that despite fossil is an executable it does not
> prevent if from exporting functions for other programs to use (at
> least on Windows, am not sure if this is possible on *nix).
It doesn't matter how the program is linked. Fossil
On Thu, Oct 6, 2011 at 10:55 AM, Gilles wrote:
> On Thu, 6 Oct 2011 10:30:46 -0400, Tomek Kott
> wrote:
> >So the checkout issue I'm not sure about, because that's how I started
> using
> >winfossil as well. I have two thoughts. By default, WinFossil looks for
> >'.fsl' type extensions. This mig
Hi Stephan, All
I've just realized that despite fossil is an executable it does not
prevent if from exporting functions for other programs to use (at
least on Windows, am not sure if this is possible on *nix).
I've just made a simple test executable Prog1.exe that links to
another executable Prog
On Thu, 6 Oct 2011 10:30:46 -0400, Tomek Kott
wrote:
>So the checkout issue I'm not sure about, because that's how I started using
>winfossil as well. I have two thoughts. By default, WinFossil looks for
>'.fsl' type extensions. This might be somehow screwing things up because it
>can't match what
On Thu, Oct 6, 2011 at 9:04 AM, Stephan Beal wrote:
> There are some (a small few) features which we can't provide over JSON
> without some major workarounds and/or caveats. Namely binary data (which
> JSON cannot natively support), which means committing binary files this way
> will not be imple
So the checkout issue I'm not sure about, because that's how I started using
winfossil as well. I have two thoughts. By default, WinFossil looks for
'.fsl' type extensions. This might be somehow screwing things up because it
can't match what it expects the fossil repo to be named vs. what it is
nam
On Thu, 06 Oct 2011 16:09:45 +0200, Gilles
wrote:
>If I choose "C:\" instead, it seems to scan the whole drive, which
>takes for ever and freezes the UI.
Also, it chokes when using some non-standard characters:
"filename contains illegal characters: ... OS Cda [or] Mp3.ico"
On Thu, 6 Oct 2011 09:50:26 -0400, Tomek Kott
wrote:
> what issues did you have with it?
Maybe it's just that I didn't use it properly:
Starting with a repo I opened with the CLI and is located at the root
of the partition where I keep all the documents I work on (source
code, HTML pages, etc.).
Ooops, pressed send a little early. Meant to finish "filed bug reports".
On Thu, Oct 6, 2011 at 9:50 AM, Tomek Kott wrote:
>
> I tried WinFossil, but had issues with it.
>>
>> Understanding that WinFossil isn't a finished solution yet, what issues
> did you have with it? I've used it frequently
> I tried WinFossil, but had issues with it.
>
> Understanding that WinFossil isn't a finished solution yet, what issues did
you have with it? I've used it frequently for
commit/update/diff/checkout/sync/create/ui and those functions have all
worked. I think Ingo would love more feedback, and I he
On Thu, 6 Oct 2011 15:04:48 +0200, Stephan Beal
wrote:
>The "most important" functionality is working already (see the doc link). i
>unfortunately can't give a timetable - i hack on it as the
>time/energy/desire allow for. If you're well-versed in C, i'd be happy to
>have another developer or 3 wo
On Thu, Oct 6, 2011 at 1:56 PM, Gilles wrote:
> I tried WinFossil, but had issues with it.
>
It's not WinFossil's fault - because fossil has no well-defined standards
for output format, it is a futile exercise to create a UI around it. One of
the niches the JSON API hopes to fill is as a communi
Thanks everyone! I've found the problem:
[ijse@/etc/init.d]$ ps -ef | grep -w 6061
ijse 6061 5734 23 09:49 pts/002:30:58 /opt/google/chrome/chrome
--type=plugin --plugin-path=/opt/google/chrome/libgcflashplayer.so --lang=en-US
--channel=5734.0xbb6d8210.1440464591
ijse 6077 606
> Do we need to do something to the Fossil SSL implementation so that it can
> accept a UCC?
I don't think so.
On my Ubuntu VM Fossil doesn't complain about certificate, just clones without
any questions.
It should be the same on Mac OS X 10.4-10.6. (On 10.7 OpenSSL no longer have
root certifi
On Thu, 6 Oct 2011 12:10:15 +0200, Stephan Beal
wrote:
>Fossil is a standalone application, not a C library of functionality.
Thanks for the infos.
I think there's a market for Fossil because it's so easy to install
and use, so that anyone who needs to keep different versions of a file
would hav
2011/10/6 Jiri Navratil
> I'm back to port 443. I have to accept "Unknown SSL certificate". Sync is
> working. Is Fingerprint all right? Accept always not save me before the same
> questions. I have to find, how to avoid this "WARNING: Certificate doesn't
> match the saved certificate for this ho
On Thu, Oct 6, 2011 at 12:05 PM, Konstantin Khomoutov <
flatw...@users.sourceforge.net> wrote:
> > > (exe:6061): Gdk-WARNING **: XID collision, trouble ahead
>
ps -ef | grep -w 6061
should reveal which app it is.
--
- stephan beal
http://wanderinghorse.net/home/stephan/
___
On Thu, Oct 6, 2011 at 12:02 PM, Gilles wrote:
> Thanks for the info. Out of curiosity, what do you mean by "monolithic
> design", and why is it a problem to write a GUI?
Fossil is a standalone application, not a C library of functionality. That
means that in order to write a UI the only possib
On Thu, 6 Oct 2011 11:27:27 +0200
Lluís Batlle i Rossell wrote:
> > [ijse@~/Desktop/WorkTable/WatchWizard]$ fossil changes
> > EDITED src/js/controller/AppController.js
> > [ijse@~/Desktop/WorkTable/WatchWizard]$
> > (exe:6061): Gdk-WARNING **: XID collision, trouble ahead
>
> This output i
On Thu, 6 Oct 2011 09:05:06 +0200, Stephan Beal
wrote:
>Nope. Fossil's monolithic design doesn't lend itself well to creating GUIs.
>We're in the process of providing a solution, though - the JSON API allows
>alternate GUIs/shells to be written for fossil, but it is not yet
>feature-complete.
Tha
On Oct 6, 2011, at 10:36 , Stephan Beal wrote:
> mmap() is only used by the sqlite3 code, not fossil.
OS X uses mmap underneath when you do malloc for the large region.
--
Dmitry Chestnykh
___
fossil-users mailing list
fossil-users@lists.fossil-scm.o
On Thu, Oct 06, 2011 at 05:22:35PM +0800, i wrote:
> [ijse@~/Desktop/WorkTable/WatchWizard]$ fossil changes
> EDITED src/js/controller/AppController.js
> [ijse@~/Desktop/WorkTable/WatchWizard]$
> (exe:6061): Gdk-WARNING **: XID collision, trouble ahead
This output is not from fossil. I bet it
[ijse@~/Desktop/WorkTable/WatchWizard]$ fossil changes
EDITED src/js/controller/AppController.js
[ijse@~/Desktop/WorkTable/WatchWizard]$
(exe:6061): Gdk-WARNING **: XID collision, trouble ahead
(exe:6061): Gdk-WARNING **: XID collision, trouble ahead
(exe:6061): Gdk-WARNING **: XID collisi
On Thu, Oct 6, 2011 at 10:36 AM, Stephan Beal wrote:
> bit int. However, i double that sqlite3's testing procedures would allow
> such an obvious problem to slip through.
>
lol, that shows how embedded the word "double" is in my memory. It should be
"doubt".
--
- stephan beal
http://wander
2011/10/6 Jiri Navratil
> fossil(2681) malloc: *** mmap(size=18446744067267100672) failed (error
> code=12)
> *** error: can't allocate region
> *** set a breakpoint in malloc_error_break to debug
> /Users/navratil/src/fossil/fossil: out of memory
>
i'm going to make a huge guess here...
mmap(
On 6 October 2011 02:48, Gé Weijers wrote:
>
>
> On Wed, 5 Oct 2011, Michal Suchanek wrote:
>
>> And when you find an issue with a commit that is some way back in your
>> personal branch it is more logical and easier to review your branch if
>> you append the fix to the commit where it belongs log
On Wed, Oct 5, 2011 at 11:20 PM, Matt Welland wrote:
> "fossil: unable to open file "/tmp/mrwellan/testing/test/foo.txt" for
> writing"
>
> The remainder of the message confused the developer (and me for that
> matter).
>
>
chmod 0644 foo.txt
:-?
or rm?
--
- stephan beal
http://wanderingh
On Thu, Oct 6, 2011 at 3:01 AM, Gilles wrote:
> Is there another client I should know about, free or commercial?
>
Nope. Fossil's monolithic design doesn't lend itself well to creating GUIs.
We're in the process of providing a solution, though - the JSON API allows
alternate GUIs/shells to be wr
On Thu, Oct 06, 2011 at 06:42:07AM +0200, Jiri Navratil wrote:
> I upgraded to
>
> This is fossil version 1.19 [080d27a6b2] 2011-10-05 08:00:00 UTC
>
> Not sure, what I shall do in gdb. So I have this. Please let me know, what
> next I can trace. Sorry
>
>
> fossil(2681) malloc: *** mmap(size
57 matches
Mail list logo
