[fossil-users] potential backwards-compatible solution to the multi-login problem
Hi, all, i think i've found a backwards-compatible solution to the multi-login problem and wanted to run it by people familiar with the problem so that they can spot any holes in my thought process before i start hacking... (Just a quick reminder: while the lack of multiple logins is only a minor nuisance in the HTML interface (i've never needed multiple logins), in the JSON interface it will quickly become a hurdle.) Currently the login info is stored in the user table for non-anonymous users. For anonymous users we rely 100% on the cookie/auth token, which is a hash of various things and fossil can tell if it's been tampered with. (The cookie handling is very impressive, if you ask me.) My proposal would be to store the login-related info in a new table, keeping the same fields/algorithms as we currently use in the user table. The down-side would be that we could theoretically end up with arbitrary many stale login entries in the db (which could theoretically be used as attack vectors). The up-side is that we could support multiple logins per user this way. We could periodically purge contents which are older than X minutes/days/whatever (config option), and the number of login entries are very, very unlikely to every reach a point which notably impacts the db file size (we're talking probably 100 bytes per record). We could also limit the number of concurrent logins, purging the oldest ones for a given user if we go over the limit (config option). Logins would of course be excluded from syncing, and would in effect become a part of the local fossil db file (a non-critical part - the table could be dropped/emptied without affecting fossil's behaviour except that it would effectively log everyone out). A new command could be added which would force a cleanup of any stale (optionally all) login tokens (e.g. fossil login purge). :-? -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] binary in JSON: maybe there is some hope...
On 9/21/2011 9:29 AM, Stephan Beal wrote: his proposal adds binary support to JSON without actually extending JSON with new data types. It won't help you any. All that proposal is about is an alternate, non-text serialization for JSON data to avoid the expense of converting to text and back again, e.g., for an object database or some wire transmission scenarios. Precisely because it adds no types, it doesn't have anything to say about what do I do if the data I want to send isn't one of the JSON types? -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ 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] any interest in integrating jimtcl w/fossil?
On Wed, Sep 21, 2011 at 3:53 PM, Martin S. Weber martin.we...@nist.govwrote: Yep. That's where step #1 comes in - librarization of fossil. Luckily I'll have time for that (at least rounding up an API suggestion) next week. i recently went through a very similar migration/refactoring (on a much smaller scale, but the exact same problems), and have some ideas about this. i would be VERY interested in assisting if you (or someone else) would take the reigns. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] binary in JSON: maybe there is some hope...
On Wed, Sep 21, 2011 at 3:55 PM, Joshua Paine jos...@letterblock.comwrote: Precisely because it adds no types, it doesn't have anything to say about what do I do if the data I want to send isn't one of the JSON types? From what i've read, his proposal is just that - to encode (as a string) non-JSON (primarily binary) types, basically as a list containing a type tag and the byte values. After reading over more of it, i think it might be easier/more portable (but perhaps less space-efficient) to recycle sqlite3's blob-as-text format (Xaabbccdd...). That's trivial to encode/decode in all but the most restrictive environments, though it may not be efficient to to do. e.g. in JavaScript we could decode to an array (internally a linked list or some such, so it'd have a HUGE overhead if we store only 1 byte per array element) but we can't use a string because we can't change bytes of a JS string (we can only create new strings). Some native-level JS toolkits provide a ByteArray class for efficiently handling binary data, and the new JS has various new array types for handling them. But JSON itself doesn't, so i can't rely on any of those :/. i was briefly very hopeful, but somehow i'm not anymore :/. (Nonetheless, i find his proposal interesting for other specific use cases, and might find a use for it elsewhere.) -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] Feature request: edit files via web interface
On Tue, Sep 20, 2011 at 4:22 AM, Stephan Beal sgb...@googlemail.com wrote: On Tue, Sep 20, 2011 at 1:38 AM, Joshua Paine jos...@letterblock.comwrote: On 9/19/2011 7:15 PM, Stephan Beal wrote: and JS cannot natively deal with binary data (that's coming in v5 or whatever new version is coming soon). Standard javascript doesn't have this ability yet, but individual impl have relevant capabilities. E.g., privileged JS in XUL has access to files and can get base64 strings from them, and the canvas element has a toDataURL method that returns base64 encoded data plus a tiny amount of metadata. The JS version accompanying HTMLv5 (i don't remember the version number) contains some support for binary data. Some browsers have already started implementing this and some apps already use it (e.g. gmail). So the option for binary data certainly can't be ruled out altogether. OTOH, while JS is expected to (==i expect) be the primary client, there will likely be other platforms out there for which base64 is more convenient. The data: URI scheme works well for this. There are examples on this page: http://www.websiteoptimization.com/speed/tweak/inline-images/folder-test.htmland here is a data url that may work, if it comes through properly in this email: data:image/gif;base64,R0lGODlhEAAOANUAAMyZNP/MZ7OBG8uYM4ODg8jIyLqHIriFIK58FplnAcmWMaBuCJ5sBpxqBG1tbb2KJf/mgbWCHceUL7B+GIyMjMCNKKNxC5poAsKPKreEH0tLS7+MJ6h2ENOgO/f399ypROazTrSBHLyJJKVzDe+8V97e3vjFYKt5E//0jvb29t/f3//Ub//ge8WSLf/rhf/3kdbW1mxsbP//mf///wAAACH5BAAALAAQAA4AAAaWwNkMMFBIVCmhcglYYgrJpbApq8pmD0MmIpioPLPBC0UmSxGU0kzhgrTe8IroEBIIVBJWS7qEzCwULSsAVoVVJjILDhgBAzIvkJGQJDIMMRUBLTIunJ2cIDINMQ8BGzIsqKmoHzIXMQYBBzIrtLW0HTIJDipcEwgnHCMWCwwNFwkaBCkFBDHOz9AxBAUzKSow2NnaMEhBADs= Bill ___ 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] Feature request: edit files via web interface
On Wed, Sep 21, 2011 at 10:18 AM, Bill Burdick bill.burd...@gmail.comwrote: On Tue, Sep 20, 2011 at 4:22 AM, Stephan Beal sgb...@googlemail.comwrote: On Tue, Sep 20, 2011 at 1:38 AM, Joshua Paine jos...@letterblock.comwrote: On 9/19/2011 7:15 PM, Stephan Beal wrote: and JS cannot natively deal with binary data (that's coming in v5 or whatever new version is coming soon). Standard javascript doesn't have this ability yet, but individual impl have relevant capabilities. E.g., privileged JS in XUL has access to files and can get base64 strings from them, and the canvas element has a toDataURL method that returns base64 encoded data plus a tiny amount of metadata. The JS version accompanying HTMLv5 (i don't remember the version number) contains some support for binary data. Some browsers have already started implementing this and some apps already use it (e.g. gmail). So the option for binary data certainly can't be ruled out altogether. OTOH, while JS is expected to (==i expect) be the primary client, there will likely be other platforms out there for which base64 is more convenient. The data: URI scheme works well for this. There are examples on this page: http://www.websiteoptimization.com/speed/tweak/inline-images/folder-test.htmland here is a data url that may work, if it comes through properly in this email: data:image/gif;base64,R0lGODlhEAAOANUAAMyZNP/MZ7OBG8uYM4ODg8jIyLqHIriFIK58FplnAcmWMaBuCJ5sBpxqBG1tbb2KJf/mgbWCHceUL7B+GIyMjMCNKKNxC5poAsKPKreEH0tLS7+MJ6h2ENOgO/f399ypROazTrSBHLyJJKVzDe+8V97e3vjFYKt5E//0jvb29t/f3//Ub//ge8WSLf/rhf/3kdbW1mxsbP//mf///wAAACH5BAAALAAQAA4AAAaWwNkMMFBIVCmhcglYYgrJpbApq8pmD0MmIpioPLPBC0UmSxGU0kzhgrTe8IroEBIIVBJWS7qEzCwULSsAVoVVJjILDhgBAzIvkJGQJDIMMRUBLTIunJ2cIDINMQ8BGzIsqKmoHzIXMQYBBzIrtLW0HTIJDipcEwgnHCMWCwwNFwkaBCkFBDHOz9AxBAUzKSow2NnaMEhBADs= Maybe this is obvious, but a client-side editor could use data-scheme URIs to display intermediately edited data before you commit it to Fossil. Bill ___ 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] Feature request: edit files via web interface
On Wed, Sep 21, 2011 at 5:18 PM, Bill Burdick bill.burd...@gmail.comwrote: data:image/gif;base64,R0lGODlhEAAOANUAAMyZNP/ That's very good news because it (possibly) means that many JSON-consuming clients will (probably) provide base64 en/decoding APIs so that clients can construct/destruct these. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] Feature request: edit files via web interface
On Wed, Sep 21, 2011 at 5:27 PM, Bill Burdick bill.burd...@gmail.comwrote: Maybe this is obvious, but a client-side editor could use data-scheme URIs to display intermediately edited data before you commit it to Fossil. It wasn't obvious to me, certainly. Naively i will ask: would that provide any benefit to that over e.g. base64-encoding to an arbitrary JSON field? The client has the binary data, so how/where he intends to encode it to (data URL or in the request JSON) is pretty much up to him. Or am i missing the point of the proper use of data urls? -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] Feature request: edit files via web interface
On Wed, Sep 21, 2011 at 11:10 AM, Stephan Beal sgb...@googlemail.comwrote: On Wed, Sep 21, 2011 at 5:59 PM, Bill Burdick bill.burd...@gmail.comwrote: back through a server to get it. The data scheme essentially allows a client to emulate a web server for itself (note the mime-type in the example). Thank you for the explanation. Are data URLs always (or normally) base64-encoded or do they allow arbitrary encodings? (i assume the latter since the URL contains the encoding name?) If data URLs most commonly use one format or another, i would strongly prefer to use that same format for transferring binary over JSON (simply via portability via ubiquity reasons). No problem! It looks like you can choose base-64 or ascii (with %-escaped hex octets). This covers all of the details: http://en.wikipedia.org/wiki/Data_Uri Bill ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] RFC: JSON error reporting conventions
Hi, all! Currently the JSON API reports app-level errors by setting a resultCode property to a string in the form FOSSIL- (==4-digit, left-zero-padded decimal integer). i used that because i already had code which did it and it works well in the project i stole that from. While tinkering with adding non-fatal warnings support i'm trying out plain integer values (the part of FOSSIL-) instead. So the different looks like: resultCode: FOSSIL-1234 vs resultCode: 1234 Has anyone got any strong arguments in favour of one or the other? i'm tending now towards the second form, and the only reason i haven't done it already is because the first form is used in the docs so much ;). -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] binary in JSON: maybe there is some hope...
On Wed, Sep 21, 2011 at 4:05 PM, Stephan Beal sgb...@googlemail.com wrote: From what i've read, his proposal is just that - to encode (as a string) non- It turns out i completely misunderstood what he's doing there. He's encoding the JSON itself as binary, as opposed to encoding binary data in JSON. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] any interest in integrating jimtcl w/fossil?
On 09/20/11 15:53, Martin S. Weber wrote: On 09/20/11 19:20, Steve Bennett wrote: It is the interface to fossil which is important. Yep. That's where step #1 comes in - librarization of fossil. Luckily I'll have time for that (at least rounding up an API suggestion) next week. Please keep in mind that such an API should not only help implementing language bindings for fossil but should also support tool makers. I'm working on a C# library to use fossil commands and a Windows GUI for fossil (with the goal of Visual Studio integration) and I really miss a library like the one that exists for SQLite. Implementing tools around fossil would be so much easier if a library would be available. An other thing: Seeing how much fossil developer related traffic currently is on the mailing list, maybe it is time to setup a new fossil-deve...@lists.fossil-scm.org ? I think it would make sense to split because users looking for answers regarding their day to day usage problems and not being directly interested in development of fossil should not be bothered with development topics. Maybe someone of the active developers asks Richard to set up a new list? Regards, Ingo ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Binary file merge
Hi folks, I use fossil for some LabView development (among other dev work). For those not familiar with it, it's a graphical programming environment, and the files are binary. That in itself isn't a big deal. Especially because we're provided with a merge tool. I've tested out the merge command I pass I set up in fossil (for gmerge): lvmerge %baseline %original %merge %output However, when I go to merge two branches, fossil just says * Cannot merge binary file Measurements/Resistance/DC/Get Resistance.vi without launching the merge tool. I guess the question is, does fossil even attempt to launch the gmerge tool when merging binary files? Thanks, Tomek ___ 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] any interest in integrating jimtcl w/fossil?
On 09/21/11 14:12, Ingo Koch wrote: On 09/20/11 15:53, Martin S. Weber wrote: On 09/20/11 19:20, Steve Bennett wrote: It is the interface to fossil which is important. Yep. That's where step #1 comes in - librarization of fossil. Luckily I'll have time for that (at least rounding up an API suggestion) next week. Please keep in mind that such an API should not only help implementing language bindings for fossil but should also support tool makers. Absolutely. Rest assured, I do: On 09/20/11 15:00, Martin S. Weber wrote: Of course if you're an IDE person, you'll appreciate easier integration with, say, the behemothian eclipse, the leviathan netbeans, the Zizian IDEA or the all-encompassing emacs. Sorry I forgot to mention the humongous VisualXXX ;) Regards, -Martin ___ 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] any interest in integrating jimtcl w/fossil?
On Wed, Sep 21, 2011 at 8:12 PM, Ingo Koch ingo.k...@gmx.de wrote: Please keep in mind that such an API should not only help implementing language bindings for fossil but should also support tool makers. We're all agreed on the many potential benefits, i think. The only hurdle is the size of the task. It would be a major overhaul. That's not to discount the idea - i'm all for it. i did in fact start to do this way back in 2008, but quickly found that fossil's use of exit() as an error handling strategy (which makes sense in a standalone app) was just the first of several big worms i'd have to deal with. An other thing: Seeing how much fossil developer related traffic currently is on the mailing list, maybe it is time to setup a new fossil-deve...@lists.fossil-scm.org? Richard suggested that last week, but i don't think he's gotten around to it yet. For the sake of the non-dev users, who are certainly sick of my chatter by now, i hope he (or someone else with admin access? Bueler?) finds some time for it. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] Binary file merge
On Wed, Sep 21, 2011 at 8:16 PM, Tomek Kott tkott.s...@gmail.com wrote:
I guess the question is, does fossil even attempt to launch the gmerge tool
when merging binary files?
The code says...
The merge command ends up calling merge_3way(), which does:
zGMerge = db_get(gmerge-command, 0);
if( zGMerge zGMerge[0] ){
... go run gmerge ...
}
The error string you report is not triggered until after merge_3way()
returns, and only if merge_3way() returns 0. merge_3way() returns 0 if
blob_merge() returns 0, so, which leads us to blob.c...
blob_merge() says:
** The return is 0 upon complete success. If any input file is binary,
** -1 is returned and pOut is unmodified. If there are merge
So it seems that binary merges are not supported at all (at least that's how
i interpret it).
--
- stephan beal
http://wanderinghorse.net/home/stephan/
___
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] Binary file merge
Then can I put in a feature request for gmerge to support binary file
merging? With the assumption that the user will (through a system dependent
method, like a shell script) call the appropriate binary file merger for the
binary file type passed in? That would make my (merging) life much easier. I
think that's the way that the diff command works currently.
Thanks,
Tomek
On Wed, Sep 21, 2011 at 2:35 PM, Stephan Beal sgb...@googlemail.com wrote:
On Wed, Sep 21, 2011 at 8:16 PM, Tomek Kott tkott.s...@gmail.com wrote:
I guess the question is, does fossil even attempt to launch the gmerge
tool when merging binary files?
The code says...
The merge command ends up calling merge_3way(), which does:
zGMerge = db_get(gmerge-command, 0);
if( zGMerge zGMerge[0] ){
... go run gmerge ...
}
The error string you report is not triggered until after merge_3way()
returns, and only if merge_3way() returns 0. merge_3way() returns 0 if
blob_merge() returns 0, so, which leads us to blob.c...
blob_merge() says:
** The return is 0 upon complete success. If any input file is binary,
** -1 is returned and pOut is unmodified. If there are merge
So it seems that binary merges are not supported at all (at least that's
how i interpret it).
--
- stephan beal
http://wanderinghorse.net/home/stephan/
___
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] Binary file merge
On Wed, Sep 21, 2011 at 8:42 PM, Tomek Kott tkott.s...@gmail.com wrote: Then can I put in a feature request for gmerge to support binary file merging? With the assumption that the user will (through a system dependent method, like a shell script) call the appropriate binary file merger for the binary file type passed in? That would make my (merging) life much easier. I think that's the way that the diff command works currently. IIRC (but i won't promise that i do!), this discussion came up a few years ago and the general opinion was (again, IIRC) that a binary merge is not generically possible. To merge contents of binary files the merging program has to understand their structure. e.g. i can't just (via a generic algo) replace 17 bytes of a ZIP file (binary file) with 21 (or 5 or N) bytes brought in by a merge because i'll corrupt it. The internal zip header's idea of that field is now wrong (or i might have overwritten part of that field via the merge). The same applies to any non-random binary data (but who's versioning random data?). -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] Binary file merge
To be clear, I'm not saying that fossil needs to handle the binary merge. That's why the external program is there. The user (who would generically know what kind of binary files are used in the repo) provides a shell script for the gmerge command. Fossil calls gmerge (if present) when there is a binary file (or a merge that goes haywire). The shell script goes through and decides the merge tool to use (for my case, lvmerge for the labview code) in the correct format (lvmerge %baseline %original %merge %output). In my case, this repository only handles these kinds of files, so instead of the shell script, I can call lvmerge directly. As I see it, fossil doesn't need to know what the binary file is...it just needs to call the external program. If the program can't handle it, then presumably it would return an error anyway, and hence the same error message would come out...Am I missing something? Maybe what I'm really asking for is for a fossil gmerge command that would work the same as the fossil gdiff command. CUrrently, fossil has no problem using gdiff on binary files. Tomek On Wed, Sep 21, 2011 at 2:46 PM, Stephan Beal sgb...@googlemail.com wrote: On Wed, Sep 21, 2011 at 8:42 PM, Tomek Kott tkott.s...@gmail.com wrote: Then can I put in a feature request for gmerge to support binary file merging? With the assumption that the user will (through a system dependent method, like a shell script) call the appropriate binary file merger for the binary file type passed in? That would make my (merging) life much easier. I think that's the way that the diff command works currently. IIRC (but i won't promise that i do!), this discussion came up a few years ago and the general opinion was (again, IIRC) that a binary merge is not generically possible. To merge contents of binary files the merging program has to understand their structure. e.g. i can't just (via a generic algo) replace 17 bytes of a ZIP file (binary file) with 21 (or 5 or N) bytes brought in by a merge because i'll corrupt it. The internal zip header's idea of that field is now wrong (or i might have overwritten part of that field via the merge). The same applies to any non-random binary data (but who's versioning random data?). -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] Binary file merge
On Wed, Sep 21, 2011 at 9:08 PM, Tomek Kott tkott.s...@gmail.com wrote: As I see it, fossil doesn't need to know what the binary file is...it just needs to call the external program. If the program can't handle it, then presumably it would return an error anyway, and hence the same error message would come out...Am I missing something? That makes sense to me. Maybe what I'm really asking for is for a fossil gmerge command that would work the same as the fossil gdiff command. CUrrently, fossil has no problem using gdiff on binary files. i'm trying to figure out if that's doable with a minor tweak to the current code, but i just don't see it (but i'm not at all familiar with the diff/merge code). The first problem i see with this change now is that the is-it-binary determination is made one or two levels too deep for us to respond by launching gmerge. gmerge is not launched until after blob_diff() returns (and reports success). gmerge takes 4 options: pivot original merge other. Fossil doesn't have all of those if blob_merge() fails, so it cannot call gmerge. In order to fix this it would have to figure out in advance if the object is binary and... and do what? We don't have a binary diff algo, AFAIK. At least that's my understanding of it. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] Binary file merge
On 9/21/2011 3:50 PM, Stephan Beal wrote: i'm trying to figure out if that's doable with a minor tweak to the current code, but i just don't see it (but i'm not at all familiar with the diff/merge code). The first problem i see with this change now is that the is-it-binary determination is made one or two levels too deep for us to respond by launching gmerge. gmerge is not launched until after blob_diff() returns (and reports success). gmerge takes 4 options: pivot original merge other. Fossil doesn't have all of those if blob_merge() fails, so it cannot call gmerge. In order to fix this it would have to figure out in advance if the object is binary and... and do what? We don't have a binary diff algo, AFAIK. If that's the case than I too would vote for a 'gmerge' command. Soon I will be doing the exact same thing as Tomek, where I want to handle merging of my own binary data. If necessary, when that time comes, I can look into implementing the command if someone more knowledgeable about that code doesn't beat me to it first :) Barring that, and not looking at the code right now, there could be a binary diff algo in Fossil that just reports a Failed: Can not merge binary files so if there is no user configured merge tool set, it still ends up with the same results. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
