Re: [fossil-users] SVN <--> Fossil & Chiselapp hosting
On Fri, Oct 17, 2014 at 2:59 AM, Ron W wrote: > A question about libfossil: Is it possible to directly create a delta > artifact? I ask this because it looks like SVN::Dump::Reader does not > un-delta the artifact content. So either I would have to apply the delta > myself (to provide the full text to libfossil) or convert the SVN delta > into a Fossil delta. > If by "artifact" you mean "arbitrary blob," yes libf supports fossil's delta generation, and they can be generated and applied independently of the SCM content. See the f-delta tool for an example: http://fossil.wanderinghorse.net/repos/libfossil/index.cgi/finfo?name=f-apps/f-delta.c With the relative bits being: http://fossil.wanderinghorse.net/repos/libfossil/index.cgi/info/c338817d2d1dbf7072921518c0a0a7f2aa8ea06d?ln=74-93 If by "artifact" you mean manifests/checkin records: By default it prefers deltas, but (for historical compatibility) only creates them once a delta has been seen in the given repo. It uses an algo, derived directly from fossil, which, after building the delta, figures out if is "too big to be worth the effort," and throws it away (creating a baseline instead) if it is. libf offers a force flag to force the delta generation, but doing so bypasses the "if too big..." check, and it's only intended for testing purposes or to force the introduction of an initial delta into the repo (after which libf and fossil will both prefer deltas over baselines). Caveat: libf currently only builds delta manifests in the context of a checkin operation, so it sounds like it would need to be taught to create a checkin's manifest without performing the checkin. That would require only a small bit of refactoring. The core API supports building your own manifests from scratch, but building deltas properly is tricky, best left to the library, as opposed to generating one "by hand" (where "by hand" really means "via an OO API"). The simplest way to create artifacts by hand is via the C++ API, as demonstrated here: http://fossil.wanderinghorse.net/repos/libfossil/index.cgi/info/80b312bea51eb012477b9887b6f7a55c0344a787?ln=171-178 which creates: D 2014-10-17T07:29:25.000 T *myOtherTag * T +myTag * its\svalue T -sumdumtag * U stephan Z da69975a6374f993fd6e50cae1f61a10 -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FINFO suggestion
On Fri, Oct 17, 2014 at 8:34 AM, Tony Papadimitriou wrote: > Would that be too much programming effort to add? I.e., check if > ‘filename’ is a directory and in that case return FINFO for all associated > files. > If it weren't for the -status and -print options, it would require only another loop around the bottom part of the finfo code, but as it is i think it requires moving all of finfo into another routine, then calling that from a loop in finfo. Somewhere we've got SQL code for the filename vs dir part. It looks like the next step would then be to allow multiple files (because at some point you'll just want to see the .c files, not the .h ones, and you'll want to pass src/*.c). That would change the semantics of current behaviour, though: a) currently it is fatal to pass a non-tracked file to finfo. b) when passing wildcards like dirname/*, it's going to happen fairly often that untracked files will be picked up, and it would arguably be silly to error out there. Remember that the wildcards get expanded before finfo gets them, so it cannot distinguish between wildcard expansions and other user input. Suggestions? i've got to log in to work in a few minutes, but will take a look at the first step (passing only one arg, but either a file or dir) after work. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FINFO suggestion
Not being sure I understood your approach completely, and without knowing fossil’s internals, but knowing that it uses SQL for a lot of its work, I think that mostly the related SQL would have to change. I believe a simple loop approach would just print FINFO for each file separately before processing the next one, right? But that would be out of historic order. The idea is to get the history of all matched files in the correct order, so if files A and B change, you want a display like this: A B A A B not this: A A A B B From: Stephan Beal Sent: Friday, October 17, 2014 10:59 AM To: Fossil SCM user's discussion Subject: Re: [fossil-users] FINFO suggestion On Fri, Oct 17, 2014 at 8:34 AM, Tony Papadimitriou wrote: Would that be too much programming effort to add? I.e., check if ‘filename’ is a directory and in that case return FINFO for all associated files. If it weren't for the -status and -print options, it would require only another loop around the bottom part of the finfo code, but as it is i think it requires moving all of finfo into another routine, then calling that from a loop in finfo. Somewhere we've got SQL code for the filename vs dir part. It looks like the next step would then be to allow multiple files (because at some point you'll just want to see the .c files, not the .h ones, and you'll want to pass src/*.c). That would change the semantics of current behaviour, though: a) currently it is fatal to pass a non-tracked file to finfo. b) when passing wildcards like dirname/*, it's going to happen fairly often that untracked files will be picked up, and it would arguably be silly to error out there. Remember that the wildcards get expanded before finfo gets them, so it cannot distinguish between wildcard expansions and other user input. Suggestions? i've got to log in to work in a few minutes, but will take a look at the first step (passing only one arg, but either a file or dir) after work. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FINFO suggestion
On Fri, Oct 17, 2014 at 10:16 AM, Tony Papadimitriou wrote: > Not being sure I understood your approach completely, and without > knowing fossil’s internals, but knowing that it uses SQL for a lot of its > work, I think that mostly the related SQL would have to change. > > I believe a simple loop approach would just print FINFO for each file > separately before processing the next one, right? > That's what i was thinking. > But that would be out of historic order. > The idea is to get the history of all matched files in the correct order, > so if files A and B change, you want a display like this: > Okay, that's getting a bit over my head ;). i will take a look after work, but make no promises. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] JSON Web Client not in fossil pages
On Thu, Oct 16, 2014 at 9:24 PM, Ron W wrote: > On Thu, Oct 16, 2014 at 3:14 AM, Stephan Beal > wrote: > >> i'm not aware of any WWW feature of fossil which uses checkout-level >> data except maybe to display versioned settings. >> > > For embedded documents: > baseURL/doc/version/path > if version is "ckout", then the file in the associated working space is > read, not an artifact in the > There's that, but: > This feature only works for a Fossil server started with either "fossil > server" or "fossil ui" within a working space. > i don't think any of the "public-facing" bits other than /setup_settings (aware of checkout-level versioned settings) touch a checkout. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] SVN <--> Fossil & Chiselapp hosting
On Thu, 16 Oct 2014 20:59:52 -0400 Ron W wrote: > For a project that follows the recommended convention of directories > named "trunk", "branches" and "tags" - or clearly identifies its > convention - creating branches (and tagged commits) in Fossil should > not be too hard. If the convention cannot be identified, then no > branches would be created. In any case, my opinion is that having SVN <---> Fossil is much more interested than Git <---> Fossil 'cause, imho, with Fossil one can make very familiar/similar workflow like the one used with SVN. Sincerely, Gour -- A person who is not disturbed by the incessant flow of desires — that enter like rivers into the ocean, which is ever being filled but is always still — can alone achieve peace, and not the man who strives to satisfy such desires. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FINFO suggestion
On Fri, Oct 17, 2014 at 09:59:26AM +0200, Stephan Beal wrote: > On Fri, Oct 17, 2014 at 8:34 AM, Tony Papadimitriou wrote: > > Would that be too much programming effort to add? I.e., check if > ‘filename’ is a directory and in that case return FINFO for all associated > files. > I dream about that feature since the beginning I use fossil. Alternatively, I think modifying "timeline" command/webpage to have the capability to limit it scope to one subdirectory would be nice. Imagine a team where one is dedicated to the documentation and only work in doc/, when he look at the timeline to follow his work, it's hard to track changes that was made inside doc/ directory. (especially if his college commit a lot more than him inside src/). Despite the complexity of the timeline command/webpage, I don't think it would be to hard to do. In verbose mode, timeline already list all file path affected by every checkin, we could just generate the timeline output in a temporary buffer before to output it and loop thought it at the end to discard the checkins that doesn't contain the directory we want in path of any of the affected files. > > If it weren't for the -status and -print options, it would require > only another loop around the bottom part of the finfo code, but as it > is i think it requires moving all of finfo into another routine, then > calling that from a loop in finfo. Somewhere we've got SQL code for > the filename vs dir part. > > It looks like the next step would then be to allow multiple files > (because at some point you'll just want to see the .c files, not the > .h ones, and you'll want to pass src/*.c). That would change the > semantics of current behaviour, though: I don't think this would be necessary to have wildcard to filter some specific file inside a directory. Normally, any file that changes inside one directory is susceptible to affect behavior the other files of the same directory. But with the timeline approach, it would an easy add-on I guess. -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FINFO suggestion
I guess the timeline equivalent would work, too! However, I'd be more interested in being able to see just the code changes (i.e., check-ins) and not all the 'noise' about wiki edits, tickets, tags, etc which the timeline gives by default (unless one uses the "-t ci" option). So, I thought since FINFO already only deals with file edits (ignoring all the rest), this would be the right place to do it with less changes. But, I don't know. -Original Message- From: Martin Gagnon Sent: Friday, October 17, 2014 4:56 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] FINFO suggestion On Fri, Oct 17, 2014 at 09:59:26AM +0200, Stephan Beal wrote: On Fri, Oct 17, 2014 at 8:34 AM, Tony Papadimitriou wrote: Would that be too much programming effort to add? I.e., check if ‘filename’ is a directory and in that case return FINFO for all associated files. I dream about that feature since the beginning I use fossil. Alternatively, I think modifying "timeline" command/webpage to have the capability to limit it scope to one subdirectory would be nice. Imagine a team where one is dedicated to the documentation and only work in doc/, when he look at the timeline to follow his work, it's hard to track changes that was made inside doc/ directory. (especially if his college commit a lot more than him inside src/). But with the timeline approach, it would an easy add-on I guess. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FINFO suggestion
On Fri, Oct 17, 2014 at 10:17 AM, wrote: > I guess the timeline equivalent would work, too! Please try out the change on the cmdline-timeline-enhancement branch and see if it works for you. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FINFO suggestion
On Fri, Oct 17, 2014 at 05:17:24PM +0300, to...@acm.org wrote: > I guess the timeline equivalent would work, too! However, I'd be > more interested in being able to see just the code changes (i.e., > check-ins) and not all the 'noise' about wiki edits, tickets, tags, > etc which the timeline gives by default (unless one uses the "-t ci" > option). So, I thought since FINFO already only deals with file > edits (ignoring all the rest), this would be the right place to do > it with less changes. But, I don't know. > The advantage I see with "timeline" is that it's already building a list of all checkins from a single huge SQL query (don't matter which file it touch), Then it's easy to filter out what we don't want from it. In the other hand, finfo is only building a list of checkins affecting one particular file. To be able to easily modify it for a complete sub directory is the equivalent of calling finfo multiple time and them merging result to have one consistent list. I didn't check the code in detail for finfo command, but my impression is that starting from timeline is easier and more optimized, but I could be wrong.. -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FINFO suggestion
On Fri, Oct 17, 2014 at 11:32:27AM -0400, Richard Hipp wrote: > > > On Fri, Oct 17, 2014 at 10:17 AM, wrote: > > I guess the timeline equivalent would work, too! > > > Please try out the change on the cmdline-timeline-enhancement branch > and see if > it works for you. > Nice, thanks for that... I made some basic test on a few repo, and it seems to work well. I can even "cd" to a directory and do: "fossil timeline ." and it give me only checkins affecting the current dir where I am. I've also test the "-n" options and it is consistent when specifying a directory. I guess the next step is to have that feature on the /timeline web page, and may be a "timeline" link beside each directory in the "/tree" web page.. -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FINFO suggestion
On Fri, Oct 17, 2014 at 12:01 PM, Martin Gagnon wrote: > > I guess the next step is to have that feature on the /timeline web page, > and may be a "timeline" link beside each directory in the "/tree" web > page.. > > That's harder to do because the graph is disjoint when you skip check-ins. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FINFO suggestion
On Fri, Oct 17, 2014 at 12:05:36PM -0400, Richard Hipp wrote: > > > On Fri, Oct 17, 2014 at 12:01 PM, Martin Gagnon wrote: > > > I guess the next step is to have that feature on the /timeline web page, > and may be a "timeline" link beside each directory in the "/tree" web > page.. > > > > That's harder to do because the graph is disjoint when you skip check-ins. > True, I guess we could do the same as the "u=user" query parameter where we can also have a disjoint graph. Example: http://www.fossil-scm.org/index.html/timeline?u=drh&c=2014-10-17+15%3A31%3A48&nd The timeline could be represented the same way with a kind of "path=" query parameter when checkins are not consecutive. What do you think ? -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] JSON Web Client not in fossil pages (Stephan Beal)
I was thinking this scenario to implement, Add, Commit, Push ... in this way: One host A uses JSON to communicate whit another host B, host B should be http://localhost:8080 (mainly), so due to Javascript and JSON normally runs on client side, when i for example do AJAX with JSON where http://localhost:8080 , the URL won't be the remote server else the local server activated previously with Fossil -ui CLI: Listening for HTTP requests on TCP port 8080 Launch webbrowser: start http://localhost:8080/ So to have a checkout one could for example do a AJAX request to http://localhosr:8080 /json/add?name="fooFile.txt"&path=path/To/File So build a Web client on a remote server will have sense, on otherwise, even a Web Client inside the Fossil pages will make sense, doesn't it? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] JSON Web Client not in fossil pages (Stephan Beal)
On Fri, Oct 17, 2014 at 6:39 PM, Carlos Alberto Ruiz Uribe < carlos.ru...@softtek.com> wrote: > So build a Web client on a remote server will have sense, on otherwise, > even a Web Client inside the Fossil pages will make sense, doesn’t it? > It does make sense, but the security implications make me very nervous, as well as does modifying a checkout (because every files writable over the web is a potential security hole). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FINFO suggestion
I did a quick try, and it seems to work OK with only one small exception, the root directory itself (where _FOSSIL_ is). There, “fossil tim .” for example (which works OK in subdirectories), shows nothing “+++ no more data (0) +++” when obviously there is quite a lot because if I give “fossil tim filename” I get the history of the given filename. Thanks for the change. From: Richard Hipp Sent: Friday, October 17, 2014 6:32 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] FINFO suggestion On Fri, Oct 17, 2014 at 10:17 AM, wrote: I guess the timeline equivalent would work, too! Please try out the change on the cmdline-timeline-enhancement branch and see if it works for you. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FINFO suggestion
One more problem I see is that it sometimes shows the same timeline entry multiple times in a row (same SHA1 and description) From: to...@acm.org Sent: Friday, October 17, 2014 7:51 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] FINFO suggestion I did a quick try, and it seems to work OK with only one small exception, the root directory itself (where _FOSSIL_ is). There, “fossil tim .” for example (which works OK in subdirectories), shows nothing “+++ no more data (0) +++” when obviously there is quite a lot because if I give “fossil tim filename” I get the history of the given filename. Thanks for the change. From: Richard Hipp Sent: Friday, October 17, 2014 6:32 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] FINFO suggestion On Fri, Oct 17, 2014 at 10:17 AM, wrote: I guess the timeline equivalent would work, too! Please try out the change on the cmdline-timeline-enhancement branch and see if it works for you. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] JSON Web Client not in fossil pages (Stephan Beal)
You're right about security holes or issues, but what i mean is : Web client is just sending JSON commands to a local host that operates locally, the operations are not on internet , i mean it will be like to send remote commands to a local Fossil CLI, something like that but using http as the protocol together with JSON to send the commands, that will go on internet, i'don't know if fossill uses SSL or HTTPS (i guess yes) and with that i don't see a problem sending a JSON command on internet, all the operations will be local because will be made by the Fossil web server activated localy by each user, and Javascript again is running on client side... of cousse if you don't use SSL or HTTPS the javascript could be viewed by a sniffer but also the actual JSON API to just query or ask for dir or other commands can be viewed without using SSL or HTTPS. So i will study JSON and CSON in the source code to make somo proof of concept, and i will share results hardly i understand the code and can hack examples. Regards. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] JSON Web Client not in fossil pages (Stephan Beal)
On Fri, Oct 17, 2014 at 7:36 PM, Carlos Alberto Ruiz Uribe <
carlos.ru...@softtek.com> wrote:
>
>
> *You’re right about security holes or issues, but what i mean is : Web
> client is just sending JSON commands to a local host that operates locally,
> the operations are not on internet ,*
>
But the API doesn't know that. Whether the JSON comes from (the CLI or
HTTP) is abstracted away from the individual commands. Yes, it could be
done, but i would be very hesitant to do so. (Trivia: the main reason JSON
supports CLI mode at all is because that's much easier to develop and test
that way. The primary target of the JSON API is most certainly HTTP
clients.)
*So i will study JSON and CSON in the source code to make somo proof of
> concept, and i will share results hardly i understand the code and can hack
> examples.*
>
It's not difficult to add new commands to the JSON API. A good starting
point is to find an existing command's entry point function, then grep that
function name:
[stephan@host:~/cvs/fossil/fossil/src]$ grep -w json_page_user *.c
json.c:cson_value * json_page_user();
json.c:{"user",json_page_user,0},
json_user.c:cson_value * json_page_user(){
That will lead you to both the implementation and the place where that
function needs to be registered so that it shows up in the list of JSON
subcommands.
Feel free to post questions and suggestions.
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FINFO suggestion
An observation related to the last problem. The identical multiple entries seem to match the number of files that have changed in that subdirectory. So, if three files changed, the same timeline entry appears three times. From: to...@acm.org Sent: Friday, October 17, 2014 8:30 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] FINFO suggestion One more problem I see is that it sometimes shows the same timeline entry multiple times in a row (same SHA1 and description) From: to...@acm.org Sent: Friday, October 17, 2014 7:51 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] FINFO suggestion I did a quick try, and it seems to work OK with only one small exception, the root directory itself (where _FOSSIL_ is). There, “fossil tim .” for example (which works OK in subdirectories), shows nothing “+++ no more data (0) +++” when obviously there is quite a lot because if I give “fossil tim filename” I get the history of the given filename. Thanks for the change. From: Richard Hipp Sent: Friday, October 17, 2014 6:32 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] FINFO suggestion On Fri, Oct 17, 2014 at 10:17 AM, wrote: I guess the timeline equivalent would work, too! Please try out the change on the cmdline-timeline-enhancement branch and see if it works for you. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Breaking out of "fossil ui" leaves files
Hello, I just noticed something which I can't recall seeing before. I started "fossil ui" on a repository (-R foo.fossil), and when I hit ctrl-c, it terminated as expected, but it left the corresponding -shm and -wal files. I'm pretty sure I have used fossil ui on wal'd fossil repository databases before, but don't recall having to delete these files after stopping fossil ui. This coincides with having upgraded the OS my Mac, so there's that factor as well. Has there been any recent changes which might explain this, has it actually always been this way, or is it an OS behavioral change thing? A quick grep through the source leads me to believe that there is no registered signal handler to handle SIGINT apart from when an sqlite shell is started. Which leaves me slightly surprised that I haven't seen those files laying around before. -- Kind Regards, Jan ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Breaking out of "fossil ui" leaves files
On 17/10/14 20:01, Jan Danielsson wrote: [.. -wal & -shm remain after ctrl-c:ing out of fossil ui ..] >A quick grep through the source leads me to believe that there is no > registered signal handler to handle SIGINT apart from when an sqlite > shell is started. Which leaves me slightly surprised that I haven't > seen those files laying around before. ...but there is an atexit() which calls db_close(). Are the semantics regarding SIGINT vs. atexit() well-defined? -- Kind Regards, Jan ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FINFO suggestion
On Fri, Oct 17, 2014 at 08:57:50PM +0300, to...@acm.org wrote: > An observation related to the last problem. The identical multiple > entries seem to match the number of files that have changed in that > subdirectory. So, if three files changed, the same timeline entry > appears three times. > Please try latest version on the "cmdline-timeline-enhancement" branch, it should fix this issue. Since I'm not a SQL expert, I'm not sure if this very simple change doesn't break anything, but for the basic test I made, it seems to work. -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] SVN <--> Fossil & Chiselapp hosting
On Thu, Oct 16, 2014 at 8:59 PM, Ron W wrote: > > After doing some research, > More research... In the SVN dump file, deltas are optional, so an initial implementation can omit dealing with deltas. SVN dump files do not have manifests. There is a revision artifact followed by file artifacts, so the manifest would be created file-by-file. Does libfossil need a complete manifest before it can accept file data? How does libfossil expect the file content? SVN::Dump::Reader gives me a byte string that I could then either give to libfossil or write to a temp file. A caveat: SVN also has directory artifacts. As best I can tell, a "directory add" operation can safely be ignored (except the user might be expecting an empty directory to be created, so might need to "add" a placeholder file). A "directory delete" operation, however, is like "rm -r directory". Implementing this will require a way to enumerate the contents of the directory (and subdirectories). Another caveat: Due to the way SVN implements branching, a single commit can have changes from multiple branches. Hopefully no real project does this. Related to that (and previously mentioned), it is also possible for multiple files (on the same branch) in a commit to have the same "parent". Example: svn cp a.c b.c svn commit Both a.c@tip and b.c@tip will have a.c@(tip - 1) as parent. About deltas: The way SVN encodes deltas is similar enough to Fossil's delta encoding that directly converting a SVN delta to a Fossil delta may be possible. One of the caveats is that in SVN dump files, file artifacts state which commit the delta is relative to. In Fossil, it appears that the delta is always relative to the most recent commit updating the file. So it is possible for SVN to create a delta based on a different commit than Fossil assumes. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New TIMELINE with FILENAME option (WAS: FINFO suggestion)
Seems to work much better. I no longer get duplicates. Thanks. (I haven't yet checked whether the entries I see are the correct ones, e.g., no missing ones, but on first inspection the timeline seems correct). So, for now the only remaining problem I can see is the failure to show any changes for the repo root directory (using command: FOSSIL TIMELINE .) If I notice anything else, I'll report it... Thank you. -Original Message- From: Martin Gagnon Sent: Friday, October 17, 2014 10:24 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] FINFO suggestion On Fri, Oct 17, 2014 at 08:57:50PM +0300, to...@acm.org wrote: An observation related to the last problem. The identical multiple entries seem to match the number of files that have changed in that subdirectory. So, if three files changed, the same timeline entry appears three times. Please try latest version on the "cmdline-timeline-enhancement" branch, it should fix this issue. Since I'm not a SQL expert, I'm not sure if this very simple change doesn't break anything, but for the basic test I made, it seems to work. -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] SVN <--> Fossil & Chiselapp hosting
On Fri, Oct 17, 2014 at 3:25 PM, Ron W wrote: > More research... > Needing a break from dump file processing, I decided to look in to how a mirror could be kept up to date. I previously mentioned using a commit monitor, so I looked to see how one SVN repo could mirror another. I found svnsync. It's basically a SVN client that talks to 2 repos, fetching from one and committing to the other. This gave me an idea for an alternate way to import from SVN to Fossil: Implement the Fossil importer as a post commit hook to a SVN repo and use svnsync to drive it. Basically, as the target SVN repo received each commit, the post commit hook would run. Since the repo server provides the hook with a list of affected files, it could update an associated working space, then do a "fossil commit" with the list of files and any options needed to provide the commit metadata. Although this sounds like a "Rube Goldberg way" of doing it, it might actually be easier to get working. Also, because svnrdump (unlike svnadmin dump) only creates "delta dumps", it's the easiest way to keep the mirror up to date. (Almost easiest. If the main SVN repo's post commit hook sent a message with the file list and commit metadata, the extra SVN repo would not be needed.) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Breaking out of "fossil ui" leaves files
On Fri, Oct 17, 2014 at 08:10:10PM +0200, Jan Danielsson wrote: > On 17/10/14 20:01, Jan Danielsson wrote: > [.. -wal & -shm remain after ctrl-c:ing out of fossil ui ..] > >A quick grep through the source leads me to believe that there is no > > registered signal handler to handle SIGINT apart from when an sqlite > > shell is started. Which leaves me slightly surprised that I haven't > > seen those files laying around before. > >...but there is an atexit() which calls db_close(). Are the > semantics regarding SIGINT vs. atexit() well-defined? They are. No signal handler --> kernel kills the program --> atexit is not run. Joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New TIMELINE with FILENAME option (WAS: FINFO suggestion)
On Fri, Oct 17, 2014 at 10:43:53PM +0300, to...@acm.org wrote: > Seems to work much better. I no longer get duplicates. Thanks. (I > haven't yet checked whether the entries I see are the correct ones, > e.g., no missing ones, but on first inspection the timeline seems > correct). > > So, for now the only remaining problem I can see is the failure to > show any changes for the repo root directory (using command: FOSSIL > TIMELINE .) If I notice anything else, I'll report it... > Fixed now. -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New TIMELINE with FILENAME option (WAS: FINFOsuggestion)
OK, here's one more minor issue you can easily test with sqlite3 repo under Windows. Windows filenames are case insensitive. Trying with wrong case fossil tim readme.md -R sqlite3.fossil +++ no more data (0) +++ while, trying with correct case fossil tim README.md -R sqlite3.fossil === 2014-05-08 === 23:01:59 [9411d7dc6f] *MERGE* Initial attempt to merge in all trunk changes over the previous 1.5 years. This check-in compiles but there are compiler warnings and "make test" segfaults after only running a few test modules. (user: drh tags: apple-osx) === 2014-03-13 === +++ no more data (6) +++ -Original Message- From: to...@acm.org Sent: Friday, October 17, 2014 10:43 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] New TIMELINE with FILENAME option (WAS: FINFOsuggestion) Seems to work much better. I no longer get duplicates. Thanks. (I haven't yet checked whether the entries I see are the correct ones, e.g., no missing ones, but on first inspection the timeline seems correct). So, for now the only remaining problem I can see is the failure to show any changes for the repo root directory (using command: FOSSIL TIMELINE .) If I notice anything else, I'll report it... Thank you. -Original Message- From: Martin Gagnon Sent: Friday, October 17, 2014 10:24 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] FINFO suggestion On Fri, Oct 17, 2014 at 08:57:50PM +0300, to...@acm.org wrote: An observation related to the last problem. The identical multiple entries seem to match the number of files that have changed in that subdirectory. So, if three files changed, the same timeline entry appears three times. Please try latest version on the "cmdline-timeline-enhancement" branch, it should fix this issue. Since I'm not a SQL expert, I'm not sure if this very simple change doesn't break anything, but for the basic test I made, it seems to work. -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New TIMELINE with FILENAME option (WAS: FINFO suggestion)
This new timeline functionality really makes a huge difference in everyday work! Thank you all. -Original Message- From: Martin Gagnon On Fri, Oct 17, 2014 at 10:43:53PM +0300, to...@acm.org wrote: So, for now the only remaining problem I can see is the failure to show any changes for the repo root directory (using command: FOSSIL TIMELINE .) If I notice anything else, I'll report it... Fixed now. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New TIMELINE with FILENAME option (WAS: FINFOsuggestion)
On Fri, Oct 17, 2014 at 11:47:53PM +0300, to...@acm.org wrote: > OK, here's one more minor issue you can easily test with sqlite3 > repo under Windows. Windows filenames are case insensitive. Trying > with wrong case > > This one is fixed now too.. -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New TIMELINE with FILENAME option (WAS: FINFO suggestion)
Last change with case sensitivity for Windows works great. One note about the previous fix regarding the repo root. It assumes (based on comment in source) equivalence to no filename given. But this prints 'noise' like tickets, wiki edits, etc. So, I guess a simple fix is to force enable the "-t ci" option when a filename is specified in that case. Thanks for all your work. -Original Message- From: Martin Gagnon Sent: Friday, October 17, 2014 11:45 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] New TIMELINE with FILENAME option (WAS: FINFO suggestion) On Fri, Oct 17, 2014 at 10:43:53PM +0300, to...@acm.org wrote: Seems to work much better. I no longer get duplicates. Thanks. (I haven't yet checked whether the entries I see are the correct ones, e.g., no missing ones, but on first inspection the timeline seems correct). So, for now the only remaining problem I can see is the failure to show any changes for the repo root directory (using command: FOSSIL TIMELINE .) If I notice anything else, I'll report it... Fixed now. -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] SVN <--> Fossil & Chiselapp hosting
On Fri, 17 Oct 2014 16:00:08 -0400 Ron W wrote: Hello Ron, > Needing a break from dump file processing, I decided to look in to > how a mirror could be kept up to date. Thank you very much for taking time in doing this research... > Although this sounds like a "Rube Goldberg way" of doing it, it might > actually be easier to get working. Heh...now we can even more appreciate how Fossil is powerful and simple at the same time. ;) Now, let's hear from Stephan how does libfossil fit into it. Sincerely, Gour -- The senses, the mind and the intelligence are the sitting places of this lust. Through them lust covers the real knowledge of the living entity and bewilders him. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] SVN <--> Fossil & Chiselapp hosting
On Oct 15, 2014, at 2:18 PM, Stephan Beal wrote: > checkin [da524a7b522f] @ 2014-10-15 22:13:19 by [stephan] branch [trunk] > > initial chicken. On April 1, Fossil should use this as its default comment for commits to new trees. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New TIMELINE with FILENAME option (WAS: FINFOsuggestion)
Again, thanks for the quick fix regarding forced -t ci on filename. Works perfectly. As far as I can tell this new feature is complete! Great work! ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] SVN <--> Fossil & Chiselapp hosting
On Sat, 18 Oct 2014 00:12:07 +0200, Warren Young wrote: On Oct 15, 2014, at 2:18 PM, Stephan Beal wrote: checkin [da524a7b522f] @ 2014-10-15 22:13:19 by [stephan] branch [trunk] initial chicken. On April 1, Fossil should use this as its default comment for commits to new trees. +1 ;-) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] SVN <--> Fossil & Chiselapp hosting
On Fri, Oct 17, 2014 at 5:35 PM, Gour wrote: > On Fri, 17 Oct 2014 16:00:08 -0400 > Ron W wrote: > > Needing a break from dump file processing, I decided to look in to > > how a mirror could be kept up to date. > > Thank you very much for taking time in doing this research... Thank you for your apriciation. > > > Although this sounds like a "Rube Goldberg way" of doing it, it might > > actually be easier to get working. > > Heh...now we can even more appreciate how Fossil is powerful and simple > at the same time. ;) The dump file is still the best way because the "post commit hook" method won't preserve as much information. It's really just that there are a lot of details to work out and design/implement handling for. The main information the "post commit hook" method risks loosing is the relationship between a copied file and its copy, but Fossil doesn't have a copy command, so doesn't keep this, though I'm pretty sure it could. The main advantages of the "post commit hook" method are that the really hard stuff gets handled by SVN. and it turns out that "svnadmin load" has an option to run the post commit hook, so this would work with dump files, too. Besides the copied-copy issue, the main disadvantages of the "post commit hook" method are the need for an extra SVN repo and to have a working space to hold the individual files. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] SVN <--> Fossil & Chiselapp hosting
On Fri, Oct 17, 2014 at 6:30 PM, Ron W wrote: > > The main information the "post commit hook" method risks loosing is the > relationship between a copied file and its copy, but Fossil doesn't have a > copy command, so doesn't keep this, though I'm pretty sure it could. > Err, was too focused on the copied-copy issue. Renaming or moving a file will loose the relationship between the previous and new. This is more common than adding a new source file by copying it. However, despite what the semantics of the dump file make possible, I'm not sure that SVN actually correctly implements rename/move, so this might not be a real issue. I recall this being in the SVN bug list back when I was using SVN. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] SVN <--> Fossil & Chiselapp hosting
On Fri, Oct 17, 2014 at 6:42 AM, Gour wrote: > In any case, my opinion is that having SVN <---> Fossil is much more > interested than Git <---> Fossil 'cause, imho, with Fossil one can make > very familiar/similar workflow like the one used with SVN. Some SVN features not in Fossil: Tagging files. SVN allows properties to be attached to files as well as to commits. SVN properties are similar to Fossil tags. Fossil's artifact structure would support tagging files, but Fossil has no command to do this. SVN users might want this feature. However, simply enhancing the tag command to allow this could cause confusion when searching for a commit by tag. Copying files. "svn cp a b" copies a to b then adds b as a new file with history. That, when showing the history of b, it will include the history of a from before the copy (including any history a inherited). Again, SVN users might want this. While the 4th field of the F card could be used to "connect" b to a, we might need some way to indicate this was a copy, not a move/rename. There may be more, but this is what I've found so far. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
