On Fri, Jan 28, 2011 at 9:18 PM, Ron Wilson wrote:
> I am using Fossil version [79b7902cdd] 2011-01-01 03:06:47.
>
> In the View Ticket and Edit Ticket screens, there is a submenu
> consisting of the entires: Attach Check-ins Edit History New Ticket
> Timeline
>
> For some uses, I would like to b
I am using Fossil version [79b7902cdd] 2011-01-01 03:06:47.
In the View Ticket and Edit Ticket screens, there is a submenu
consisting of the entires: Attach Check-ins Edit History New Ticket
Timeline
For some uses, I would like to be change this menu, at the very least
to be able to remove Check-
On Sat, Jan 29, 2011 at 2:59 AM, Brian Smith wrote:
> I'd like it if "uuid" could be standardized on. It took me a couple
> looks to notice that "#" was uuid.
> I realize this likely just means changing the SQL in this particular
> case, but, I should be able to get the "uuid" key out of every si
On Fri, Jan 28, 2011 at 5:53 PM, Stephan Beal wrote:
> Sorry for all the noise tonight/this morning, but i'm on a hacking high...
>
> How's this for tickets info?
>
> stephan@ludo:~/cvs/fossil/fossil-sgb$ ./fossil tick list reports
> Available reports:
> report number report title
> 0 full t
Sorry for all the noise tonight/this morning, but i'm on a hacking high...
How's this for tickets info?
stephan@ludo:~/cvs/fossil/fossil-sgb$ ./fossil tick list reports
Available reports:
report numberreport title
0full ticket export
1All Tickets
2All open tickets.
3Open by ty
Yo!
The json code is now available via fossil:
http://fossil.wanderinghorse.net/repos/fossil-sgb/index.cgi/timeline?r=sgb-cson
i would welcome contributors (just send me your preferred user name and i'll
get you set up).
The new code compiles cleanly in gcc's -std=c89 mode with the
-Wall/-ansi/
On Fri, Jan 28, 2011 at 6:15 PM, Stephan Beal wrote:
> Hi, Richard!
>
> i'm trying to set up a repo where i can store my json changes for the time
> being. What i did was:
>
> - cloned official fossil repo.
> - used 'ui' to set up admin access for myself, and clone access for
> anon/guest, on my
On Sat, Jan 29, 2011 at 12:15 AM, Stephan Beal wrote:
> Error: login failed
>
My UTMOST apologies - i didn't see that part. Doh.
--
- stephan beal
http://wanderinghorse.net/home/stephan/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.
On Sat, Jan 29, 2011 at 12:15 AM, Stephan Beal wrote:
> i could send you the repo, but... you've already got it. It's just a clone
> of the main repo.
>
> Any ideas?
>
Something comes to mind, but just a theory: maybe my provider is killing the
process if it uses too much memory and/or cpu time.
Hi, Richard!
i'm trying to set up a repo where i can store my json changes for the time
being. What i did was:
- cloned official fossil repo.
- used 'ui' to set up admin access for myself, and clone access for
anon/guest, on my copy.
- scp'd it to my provider.
- Set up my cgi script
When i clone
On Fri, Jan 28, 2011 at 11:42 PM, Clark Christensen wrote:
> Good. This is nice, and complete, as far as I'm concerned. Thanks for
> taking this on, and for changing to the "fat" format.
>
My pleasure. The addition to the json lib took me all of 15 minutes, and
required a 3-byte change in fossi
Hi, all!
As the subject says (and in reference to the previous thread on the subject,
in case you've missed it):
what data/structure do we want from the wiki? What comes to mind:
- List of pages, perhaps with version info, e.g. fossil wiki json list
- Whole pages, e.g.: fossil wiki json page [Pa
>How about we agree on leaving the column names and the rows will be in "fat"
>structure?
>
>For those who must do things in a certain order, they can traverse each row's
>properties
>
>using the keys from the "columns" list. Those who don't care
>(granted, 98+% of cases) can ignore it.
Go
On Fri, Jan 28, 2011 at 2:01 PM, Stephan Beal wrote:
> On Fri, Jan 28, 2011 at 10:39 PM, Brian Smith wrote:
>>
>> Absolutely. I hope I wasn't coming off as belligerent. I like the
>> half-way compromise.
>
> LOL! By no means did you come across as belligerent.
>
Good.
>
> i'm currently looking
On Fri, Jan 28, 2011 at 10:39 PM, Brian Smith wrote:
> Absolutely. I hope I wasn't coming off as belligerent. I like the
> half-way compromise.
>
LOL! By no means did you come across as belligerent.
i'm currently looking into how i can do this for the cgi interface, but i
think i'll have to add
On Fri, Jan 28, 2011 at 1:24 PM, Stephan Beal wrote:
> On Fri, Jan 28, 2011 at 10:16 PM, Brian Smith wrote:
>>
>> My point in all this being that having the column list seems
>> unnecessary. Adding in output for a small
>> minority of users/usecases doesn't seem worth while. Even if that
>> outpu
On Fri, Jan 28, 2011 at 10:16 PM, Brian Smith wrote:
> My point in all this being that having the column list seems
> unnecessary. Adding in output for a small
> minority of users/usecases doesn't seem worth while. Even if that
> output will be trivially compressed anyway.
>
> Being pedantic,
>
On Fri, Jan 28, 2011 at 12:34 PM, Stephan Beal wrote:
>
>
> On Fri, Jan 28, 2011 at 9:14 PM, Brian Smith wrote:
>>
>> On Fri, Jan 28, 2011 at 12:09 PM, Stephan Beal
>> wrote:
>> > On Fri, Jan 28, 2011 at 9:07 PM, Joshua Paine
>> > wrote:
>> >>
>> >> Your format is certainly lighter over the wir
On Fri, Jan 28, 2011 at 9:34 PM, Stephan Beal wrote:
> i have no special love for it. How's this:
>
There is example code and demos of both formats here:
http://fossil.wanderinghorse.net/repos/cson/index.cgi/wiki?name=cson_sqlite3
(man, i love having a wiki in my repo.)
--
- stephan beal
On Fri, Jan 28, 2011 at 9:14 PM, Brian Smith wrote:
> On Fri, Jan 28, 2011 at 12:09 PM, Stephan Beal
> wrote:
> > On Fri, Jan 28, 2011 at 9:07 PM, Joshua Paine
> > wrote:
> >>
> >> Your format is certainly lighter over the wire, but it's very much not
> >> how users of JSON generally do things
On Fri, Jan 28, 2011 at 12:09 PM, Stephan Beal wrote:
> On Fri, Jan 28, 2011 at 9:07 PM, Joshua Paine
> wrote:
>>
>> Your format is certainly lighter over the wire, but it's very much not
>> how users of JSON generally do things and expect things to work. I think
>> it's worth some bytes to be un
On Fri, Jan 28, 2011 at 9:07 PM, Joshua Paine wrote:
> Your format is certainly lighter over the wire, but it's very much not
> how users of JSON generally do things and expect things to work. I think
> it's worth some bytes to be unsurprising. (And you can always gzip it
> over the wire, which wi
Your format is certainly lighter over the wire, but it's very much not
how users of JSON generally do things and expect things to work. I think
it's worth some bytes to be unsurprising. (And you can always gzip it
over the wire, which will remove most of the size difference.)
--
Joshua Paine
L
On Fri, Jan 28, 2011 at 9:04 PM, Stephan Beal wrote:
> a) in large JSON outputs the extra copies of the keys add significant
> amounts to the data size. JSON is often the format of choice because it's so
> compact.
> b) In most JSON-reading languages (primarily JS), it is trivial to
> normalize t
On Fri, Jan 28, 2011 at 9:00 PM, Richard Hipp wrote:
> I'm not using the code and so I could be wrong. But it seems to me that
> the output would be more useful as an array of objects:
>
> [{"rid":10733, "uuid":"136ac24170b24db53197c00154d4424558e28eda",...},
> {"rid":10732, "uuid":"13165785e1d
On 01/28/2011 02:41 PM, Stephan Beal wrote:
> stephan@ludo:~/cvs/fossil/fossil$ ./fossil time -json -n 2
> {
> "columns":[
> "rid",
> "uuid",
> "mDateTime",
> "comment",
> "primPlinkCount",
> "plinkCount",
> "mtime"
> ],
> "rows":[
It's awesome that you're adding this, but FWIW this is not ho
I'm not using the code and so I could be wrong. But it seems to me that the
output would be more useful as an array of objects:
[{"rid":10733, "uuid":"136ac24170b24db53197c00154d4424558e28eda",...},
{"rid":10732, "uuid":"13165785e1deb2de3b1fb9014f5c7c7b290f0f4e",...},
...]
Your output is an ob
On Fri, Jan 28, 2011 at 8:12 PM, Richard Hipp wrote:
> Please read
> http://www.fossil-scm.org/fossil/doc/trunk/src/makeheaders.html which
> explains the motiation and operation of makeheaders. Once you see how it
> works, the solution to the problems above will be trivial.
>
The problem i was
On Fri, Jan 28, 2011 at 2:48 PM, Stephan Beal wrote:
>
> There are a couple of fixmes/todos:
>
> - output to cgi_printf() when in CGI mode. First need to find how to set
> the response content type to application/json.
>
cgi_set_content_type("application/json");
--
D. Richard Hipp
d...@sqlit
On Fri, Jan 28, 2011 at 8:41 PM, Stephan Beal wrote:
> stephan@ludo:~/cvs/fossil/fossil$ ./fossil time -json -n 2
>
For the curious, here's what the code looks like, minus the "AS" tags i had
to add to the SQL and the new json lib:
in timeline_cmd():
int const isJson = (NULL == find_option("
On Fri, Jan 28, 2011 at 8:12 PM, Richard Hipp wrote:
> Please read
> http://www.fossil-scm.org/fossil/doc/trunk/src/makeheaders.html which
> explains the motiation and operation of makeheaders. Once you see how it
> works, the solution to the problems above will be trivial.
>
Will do. In the me
On Fri, Jan 28, 2011 at 1:22 PM, Stephan Beal wrote:
> On Fri, Jan 28, 2011 at 7:13 PM, Stephan Beal wrote:
>
>> i'm trying to add cson_amalgamation.[ch] to the src dir in fossil. i've
>> updated makemake.tcl, but when i build,
>> main.mk is generating a cson_amalgamation.h which is stripped of t
Just wanted to let you all know that the proposed solution is now in
the "symlinks" branch:
http://www.fossil-scm.org/index.html/timeline?r=symlinks
(I combined all my changes into a single commit -- hate to do this,
but I had some other public branches and files in my clone that I
didn't want
Just retried and I have to admit it did not work this time. Notepad
complained about the access being refused.
Strange, I probably did something wrong the first time. :)
Regards,
On Fri, Jan 28, 2011 at 2:02 PM, Heinrich Huss <
heinrich.h...@psh-consulting.de> wrote:
> Strange not on my sytstem
Strange not on my sytstem. A link to a directory remains a link to a
directory and a link to a file remains a link to a file.
Bothe cannot be swapped and i if try to access the one of the wron
type I get access denied.
It's Windows 7 Professional 64bit. I did these test as Adminitrator.
Ma
After the echo command, I tried "notepad i_am_a_link" (which was the name of
the link) and it opened the file.
The type may not be changed but the target is found anyway.
On Fri, Jan 28, 2011 at 1:49 PM, Heinrich Huss <
heinrich.h...@psh-consulting.de> wrote:
> In my test the link is still a lin
In my test the link is still a link to a directory .
if I try 'type linkname' it says 'access denied'.
Regards
Hein
Am 28.01.2011 um 19:16 schrieb Alexandre Sénéchal:
Yes, it just points to the newly created file. At least on Windows 7
64-bits. Note that you need elevated privilege to crea
On Jan 28, 2011, at 7:29 PM, Stephan Beal wrote:
> Which means fossil must run as a privileged user if it wants to support links.
>
> Can of Worms!
On Windows. With "allow-symlinks" option turned on.
If we implement it on Windows at all (that's why I didn't do it) :-)
--
Dmitry Chestnykh
2011/1/28 Alexandre Sénéchal
> Yes, it just points to the newly created file. At least on Windows 7
> 64-bits. Note that you need elevated privilege to create the link.
Which means fossil must run as a privileged user if it wants to support
links.
Can of Worms!
--
- stephan beal
http://w
On Fri, Jan 28, 2011 at 7:22 PM, Stephan Beal wrote:
> i'll take a look at the special-case option. My primary concern is that i
> can't use the typedefs i need from timeline.c and friends.
>
The special-case option seems to work great. Thanks for the tip.
--
- stephan beal
http://wanderin
On Fri, Jan 28, 2011 at 7:13 PM, Stephan Beal wrote:
> i'm trying to add cson_amalgamation.[ch] to the src dir in fossil. i've
> updated makemake.tcl, but when i build,
> main.mk is generating a cson_amalgamation.h which is stripped of typedefs
> for opaque struct types which the API needs, so it
On Fri, Jan 28, 2011 at 1:18 PM, Dmitry Chestnykh
wrote:
> On Jan 28, 2011, at 7:16 PM, Alexandre Sénéchal wrote:
>
> > Yes, it just points to the newly created file. At least on Windows 7
> 64-bits.
>
> Awesome. But I wonder why it needs "/d" flag then? :-)
>
That I cannot tell.
>
> > Note tha
On Fri, Jan 28, 2011 at 1:13 PM, Stephan Beal wrote:
> This is mostly aimed at Richard, but anyone who happens to know...
>
> i'm trying to add cson_amalgamation.[ch] to the src dir in fossil. i've
> updated makemake.tcl, but when i build,
> main.mk is generating a cson_amalgamation.h which is st
On Jan 28, 2011, at 7:16 PM, Alexandre Sénéchal wrote:
> Yes, it just points to the newly created file. At least on Windows 7 64-bits.
Awesome. But I wonder why it needs "/d" flag then? :-)
> Note that you need elevated privilege to create the link.
This is bad.
--
Dmitry Chestnykh
__
Yes, it just points to the newly created file. At least on Windows 7
64-bits. Note that you need elevated privilege to create the link.
On Fri, Jan 28, 2011 at 1:11 PM, Dmitry Chestnykh
wrote:
> On Jan 28, 2011, at 7:02 PM, Alexandre Sénéchal wrote:
>
> > I just tried it out.
> > Seems to behave
This is mostly aimed at Richard, but anyone who happens to know...
i'm trying to add cson_amalgamation.[ch] to the src dir in fossil. i've
updated makemake.tcl, but when i build,
main.mk is generating a cson_amalgamation.h which is stripped of typedefs
for opaque struct types which the API needs,
On Jan 28, 2011, at 7:02 PM, Alexandre Sénéchal wrote:
> I just tried it out.
> Seems to behave like in Unix. The link stays and if used it will report that
> the file/directory cannot be found.
> In the case of the echo command, it creates a file and the link points to it.
So, if a link pointed
Hi,
I just tried it out.
Seems to behave like in Unix. The link stays and if used it will report that
the file/directory cannot be found.
In the case of the echo command, it creates a file and the link points to
it.
Best regards,
On Fri, Jan 28, 2011 at 12:43 PM, Dmitry Chestnykh
wrote:
> On
On Fri, Jan 28, 2011 at 12:37 PM, Stephan Beal wrote:
>
> Huge Can of Worms!
>
>
Amen, brother. I cannot express how delighted I am that y'all are dealing
with this and not me! Please do continue your efforts with my blessings and
do not think it amiss if I leave the issue in your capable hands
On Jan 28, 2011, at 6:37 PM, Stephan Beal wrote:
> On Fri, Jan 28, 2011 at 6:26 PM, Dmitry Chestnykh
> wrote:
> $ ln -s randomfilename newlink
>
> We don't know what kind of link it is -- folder or file, because
> "randomfilename" doesn't exist.
>
> Not only that, if the file does exist and i
On Fri, Jan 28, 2011 at 6:26 PM, Dmitry Chestnykh
wrote:
> $ ln -s randomfilename newlink
>
> We don't know what kind of link it is -- folder or file, because
> "randomfilename" doesn't exist.
>
Not only that, if the file does exist and is subsequently removed or
replaced with the other type, wha
On Jan 28, 2011, at 18:18 , Dmitry Chestnykh wrote:
> On Jan 28, 2011, at 6:03 PM, Remigiusz Modrzejewski wrote:
>
In that case the F-card access permissions could be extended further with
"ld" for link to directory and "lf" for link to file when the link is
first imported into
On Jan 28, 2011, at 6:05 PM, Doug Currie wrote:
>> But the target file or directory could not exist at all, so it won't solve
>> the problem.
> What is "the problem?" I thought the problem was knowing if the link to be
> created was to a directory or to a file.
Exactly. But we don't know if the
On Jan 28, 2011, at 6:03 PM, Remigiusz Modrzejewski wrote:
>>> In that case the F-card access permissions could be extended further with
>>> "ld" for link to directory and "lf" for link to file when the link is first
>>> imported into Fossil. This would matter only when the link is created in a
Hi, all!
A couple weeks ago we spoke about generating JSON output for some of the
fossil features, e.g. the timeline.
Today i put together some "sqlite3 to JSON" code which will make adding this
support to fossil trivial. Here's a brief demonstration:
char const * select = "SELECT * FROM stu
On Jan 28, 2011, at 11:52 AM, Dmitry Chestnykh wrote:
> On Jan 28, 2011, at 5:08 PM, Doug Currie wrote:
>> Do all supported platforms have the equivalent of stat() to see if a linked
>> object is a directory or a file?
>>
>> In that case the F-card access permissions could be extended further w
On Jan 28, 2011, at 17:52 , Dmitry Chestnykh wrote:
> On Jan 28, 2011, at 5:08 PM, Doug Currie wrote:
>> Do all supported platforms have the equivalent of stat() to see if a linked
>> object is a directory or a file?
>>
>> In that case the F-card access permissions could be extended further wit
>
> On Fri, Jan 28, 2011 at 11:36 AM, Michael Richter wrote:
>
>> I'm trying to do some stuff with base urls in my header and I can't seem
>> to get it to work. Part of the problem is that $home is a relative address.
>> It occurs to me that I have absolutely no idea what all the $variables are
>
On Jan 28, 2011, at 5:08 PM, Doug Currie wrote:
> Do all supported platforms have the equivalent of stat() to see if a linked
> object is a directory or a file?
>
> In that case the F-card access permissions could be extended further with
> "ld" for link to directory and "lf" for link to file wh
On Fri, Jan 28, 2011 at 11:36 AM, Michael Richter wrote:
> I'm trying to do some stuff with base urls in my header and I can't seem to
> get it to work. Part of the problem is that $home is a relative address.
> It occurs to me that I have absolutely no idea what all the $variables are
> in Foss
I'm trying to do some stuff with base urls in my header and I can't seem to
get it to work. Part of the problem is that $home is a relative address.
It occurs to me that I have absolutely no idea what all the $variables are
in Fossil. Is there a list of them anywhere (I couldn't find one in the
On Jan 28, 2011, at 9:55 AM, Ron Wilson wrote:
> On Fri, Jan 28, 2011 at 6:31 AM, Dmitry Chestnykh
> wrote:
>> For example, imagine checking in the link to "../README", where README is
>> located outside
>> our repository. What link should be created in this case on Windows --
>> directory sym
On Fri, Jan 28, 2011 at 6:31 AM, Dmitry Chestnykh
wrote:
> For example, imagine checking in the link to "../README", where README is
> located outside
> our repository. What link should be created in this case on Windows --
> directory symlink or
> file symlink?
Directory. For reasons in my ear
On Jan 28, 2011, at 3:01 PM, Joerg Sonnenberger wrote:
> This is actually not true. You can't open them in the win32 subsystem,
> the SFU subsystem isn't effected by the DOS legacy...
Well, it's also not true in case you run Fossil on Linux in VMware on Windows
:-)
--
Dmitry Chestnykh
___
On Fri, Jan 28, 2011 at 02:23:06PM +0100, Dmitry Chestnykh wrote:
> On Jan 28, 2011, at 2:07 PM, Stephan Beal wrote:
>
> > Having empty text files "on platforms which do not support them" DOES
> > break the tree because the underlying files are now different (and
> > have different semantics) on
On Jan 28, 2011, at 2:07 PM, Stephan Beal wrote:
> Having empty text files "on platforms which do not support them" DOES
> break the tree because the underlying files are now different (and
> have different semantics) on different platforms. If i then copy such
> a checked-out source tree over
On Fri, Jan 28, 2011 at 1:52 PM, Dmitry Chestnykh
wrote:
> But we still _must_ handle them somehow. The current (pre-symlink) behavior
> depends on a "good" state of working directory -- that you won't use
> symlinks in an incompatible way. And you can discover the incompatible
> behavior only aft
On Jan 28, 2011, at 12:43 PM, Stephan Beal wrote:
> It cannot work transparently across platforms, period, and there are
> good reasons why so few source control systems attempt to version
> them. Symlinks are platform-specific convenience objects, and not a
> feature which can be portably emul
On Jan 28, 2011, at 12:43 PM, Stephan Beal wrote:
> i, for one, am against adding symlinks support for exactly these types of
> reasons. Too many questions regarding their portable use cannot be answered
> (and some of them are purely philosophical rather than technical, e.g.
> whether or not t
On Jan 28, 2011, at 12:43 , Stephan Beal wrote:
> i, for one, am against adding symlinks support for exactly these types of
> reasons. Too many questions regarding their portable use cannot be answered
> (and some of them are purely philosophical rather than technical, e.g.
> whether or not to al
On Fri, Jan 28, 2011 at 12:31 PM, Dmitry Chestnykh
wrote:
>
This will work when symlinks point to files/folders inside our repository,
> but what to do with other links?
> For example, imagine checking in the link to "../README", where README is
> located outside our repository. What link should
Now, the next major pain: Windows requires you to know whether the target path
of symlink is a directory or a file in order to create symlink. How to handle
this?
We cannot use Fossil's create_symlink() function during checkout, because when
checking out, some files may not yet exist. We can h
On Jan 28, 2011, at 9:33 AM, Petr Man wrote:
> On Fri, Jan 28, 2011 at 02:16, Dmitry Chestnykh
> wrote:
>> http://msdn.microsoft.com/en-us/library/aa365460(VS.85).aspx
>
> I think it means 31 in depth.
Ah, good, thanks for clarifying. Then it's not that bad.
--
Dmitry Chestnykh
_
On Fri, Jan 28, 2011 at 02:16, Dmitry Chestnykh wrote:
> http://msdn.microsoft.com/en-us/library/aa365460(VS.85).aspx
I think it means 31 in depth.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/
On Fri, Jan 28, 2011 at 06:19, Ron Wilson wrote:
> How about NTFS Junction Points? Those are supported in XP, which is
> the version of Windows we need to use where I work.
>
> Also, unlike shortcuts, they are transparent to applications that are
> unaware of them - much like real symlinks.
They
75 matches
Mail list logo
