[fossil-users] Fwd: suggestion on fossil
Richard Hipp
From: Yujianbin <yuji...@huawei.com>
Date: 2011/10/18
Subject: suggestion on fossil
To: "d...@hwaci.com" <d...@hwaci.com>
Hi, D. Richard Hipp,
I have two suggestion on fossil:
(1) support LDAP. It is a essential function for a large enterprise to manage users login and authentication.
(2) support lock command, http://veracity-scm.org has this command.
Justin Yu
俞健斌
华为技术有限公司 Huawei Technologies Co., Ltd.
Mobile: +86-13316882199
Email: yuji...@huawei.com
地址：深圳市龙岗区坂田华为基地 邮编：518129
Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com
本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
--
D. Richard Hipp
d...@sqlite.org
Remigiusz Modrzejewski
On Oct 19, 2011, at 2:18 PM, Richard Hipp wrote:
> I have two suggestion on fossil:****
>
> (1) support LDAP. It is a essential function for a large enterprise to
> manage users login and authentication.****
>
> (2) support lock command, http://veracity-scm.org has this command.****
My $0.02: both seem to be pretty valid points...
_______________________________________________
fossil-users mailing list
fossil...@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Lluís Batlle i Rossell
> ---------- Forwarded message ----------
> From: Yujianbin <yuji...@huawei.com>
>
As Yujianbin mentions veracity... I saw some videos about veracity. From the web
page, the author seems quite inspired by fossil, but on the presentation about
veracity, he did not mention fossil at all.
http://www.ericsink.com/entries/oscon_2011_video.html
I saw that as a not fair presentation, on that regard.
In any case, I wanted to try veracity, and for example it still lacks
'annotate', which for me is a basic command to have. Not that I like much its
'vv log' result either.
The author also clearly said that veracity 'is not community software', so he is
not going to accept regular contributions as his company develops the product,
but he may accept patches.
Whether to support locks... I think it can help some users, but I don't have use
cases in my day to day.
Regards,
Lluís.
Stephan Beal
Whether to support locks... I think it can help some users, but I don't have use
cases in my day to day.
----- stephan beal
http://wanderinghorse.net/home/stephan/
Ron Aaron
context? (that was my 2 NIS)
On 10/19/2011 02:50 PM, Stephan Beal wrote:
>
> My 0.02€: in some 16 years of using source control, i have never once
> had a use for (and sometimes been hindered by) locks. IMO anyone who
> _thinks_ they need them is still living in the 1980's or early 1990's.
>
dexen deVries
> On Oct 19, 2011, at 2:18 PM, Richard Hipp wrote:
> > I have two suggestion on fossil:****
> >
> > (1) support LDAP. It is a essential function for a large enterprise to
> > manage users login and authentication.****
> >
> > (2) support lock command, http://veracity-scm.org has this command.****
>
> My $0.02: both seem to be pretty valid points...
My EUR 0.02: locking creates surprising roadblock once the team grows larger
(say, >16 developers, or >8 when distributed geographically). At prev
workplace, locks placed carelessly by colleauges from remote offices caused us
to miss some deadlines. Of course, it was possible to work 'em around, but it
took good understaing of VCS & left some mess in revision history.
Why does Veracity tout explicit support for file renames? From what I've seen
in Git, the implicit rename model is much more robust -- it does not depend on
human factor -- on remembering to issue the right command when moving files
around.
--
dexen deVries
[[[↓][→]]]
Lluís Batlle i Rossell
> And furthermore, how exactly do "locks" work in a distributed SCM
> context? (that was my 2 NIS)
I think that the veracity documentation totally deludes. :) But it may be
intended, as it's a product of sourcegear. Eric wrote a book about it... and his
message is (I think) "buy the book".
Stephan Beal
I think that the veracity documentation totally deludes. :) But it may be
intended, as it's a product of sourcegear. Eric wrote a book about it... and his
message is (I think) "buy the book".
Ron Aaron
headache waiting to happen. Relying on people following "intentions" of
the software is not very robust.
Eric Sink
> IMO anyone who
> _thinks_ they need them is still living
> in the 1980's or early 1990's.
Tell that to the gaming companies. They use version control,
and their repositories contain large numbers of very large
binary files (images). The absence of locks in the DVCS world
is the main reason they can't really consider getting off
Perforce.
The ONLY reason Veracity has locks is for this use case.
--
E
On 10/19/11 7:50 AM, Stephan Beal wrote:
> 2011/10/19 Lluís Batlle i Rossell <viri...@gmail.com
> <mailto:viri...@gmail.com>>
Eric Sink
Er, no. The book is free.
I mean actually, er, free. In both electronic and paper forms.
You can get the book in HTML, PDF or EPUB here:
The paper version is 288 pages in full color. We've shipped
out over 13,000 copies, including free postage, to people all
over the world.
--
E
On 10/19/11 7:56 AM, Stephan Beal wrote:
> 2011/10/19 Lluís Batlle i Rossell <viri...@gmail.com
> <mailto:viri...@gmail.com>>
Dmitry Chestnykh
wrote:
> My 0.02€: in some 16 years of using source control, i have never
> once had a use for (and sometimes been hindered by) locks. IMO anyone
> who _thinks_ they need them is still living in the 1980's or early
> 1990's.
Just for fun: a lock sitting in FVWM CVS repository since 2008:
http://www.mail-archive.com/fvwm-w...@lists.math.uh.edu/msg15603.html
--
Dmitry Chestnykh
http://www.codingrobots.com
Lluís Batlle i Rossell
> You can get the book in HTML, PDF or EPUB here:
>
> http://www.ericsink.com/vcbe/
I was sure you were in this list ;)
Thank you for the link!
Dmitry Chestnykh
wrote:
> So the master plan is to create an SCM for the sole purpose of
> selling books about the SCM (whose sole purpose is to sell a book
> about...)?
Actually, Eric gave away this book ;-)
--
Dmitry Chestnykh
http://www.codingrobots.com
Lluís Batlle i Rossell
>
> > IMO anyone who
> > _thinks_ they need them is still living
> > in the 1980's or early 1990's.
>
> Tell that to the gaming companies. They use version control,
> and their repositories contain large numbers of very large
> binary files (images). The absence of locks in the DVCS world
> is the main reason they can't really consider getting off
> Perforce.
>
> The ONLY reason Veracity has locks is for this use case.
People use DVCS not only in the scenarios of
lost-connection-to-a-central-server. Here, most of the time, we have a
connection to it. fossil autosync is also related to that.
Having locks helps a lot managing binary files in a team, I'm sure of that. And
having DVCS implementing them so they work well in the connected-to-the-server
scenario sounds very good.
I just did not have the need of them, but I might some day.
Remigiusz Modrzejewski
On Oct 19, 2011, at 2:50 PM, Stephan Beal wrote:
> 2011/10/19 Lluís Batlle i Rossell <viri...@gmail.com>
>
>> Whether to support locks... I think it can help some users, but I don't
>> have use
>> cases in my day to day.
>>
>
> My 0.02€: in some 16 years of using source control, i have never once had a
> use for (and sometimes been hindered by) locks. IMO anyone who _thinks_ they
> need them is still living in the 1980's or early 1990's.
I seem to be still in the 80's... So how do you cope with edit conflicts on binary files today? And yes, this actually happened to me, one of us applied some pretty gradients to icons, while the other changed their shape...
Kind regards,
Remigiusz Modrzejewski
Kevin Greiner
I think that the veracity documentation totally deludes. :) But it may be
intended, as it's a product of sourcegear. Eric wrote a book about it... and his
message is (I think) "buy the book".
Stephan Beal
On Oct 19, 2011, at 2:50 PM, Stephan Beal wrote:
> My 0.02€: in some 16 years of using source control, i have never once had a
> use for (and sometimes been hindered by) locks. IMO anyone who _thinks_ they
> need them is still living in the 1980's or early 1990's.
I seem to be still in the 80's... So how do you cope with edit conflicts on binary files today?
Stephan Beal
Alaric Snell-Pym
Hash: SHA1
On 10/19/2011 03:52 PM, Stephan Beal wrote:
> Could a new "special" tag be used to implement lock-like behaviour? By
> "special" i mean a reserved name (or name pattern, e.g. locked-by-USERNAME).
Tags apply to whole commits, though, not individual files. Perhaps
lock/unlock actions should be implemented as a special commit that
changes no file data, but changes a "locked by <foo>" property of the
files in the manifest. Making them slightly funny commits would mean
they appear in the history and are appropriately replicated, scoped to
branches, and all that jazz.
ABS
- --
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6e54UACgkQRgz/WHNxCGoJpACcCb2CEFRnyD3QFLJF6cBqLpGm
UHUAn2evRfMColj1Bi739+VrlDQXsj5l
=PUux
-----END PGP SIGNATURE-----
Stephan Beal
Tags apply to whole commits, though, not individual files. Perhaps
Alek Paunov
the repo consists of 13 sqlite DBs (WAL mode) + 1 external BLOB file (+
counting number simple sqlite3 files with containing table)
Michael Barrow
_______________________________________________
fossil-users mailing list
fossil...@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Michael Barrow
michael at barrow dot me
+1 (408) 782-4249
Richard Hipp
Note that Fossil works just fine with binary files. Fossil's self-hosting repository contains binary files. (See, for example, www.fossil-scm.org/fossil/artifact/590c4da59eb) I keep a private repository of all my slide presentations that is almost all binary files.
The only problem with binary files is that you cannot merge them. If you do introduce a fork on a binary file, that fork needs to be resolved manually. Locks do not help this - they do not magically enable merging. Locks just prevent the fork from happening in the first place. But Michael is right - that can be handled by administrative back-channels.
Matt Welland
As has been mentioned Locks are really helpful when managing data that can't be automatically merged. However the need is not for draconian control but more of a semaphore to prevent accidentally changing a binary file at the same time someone else does.
A more than adequate lock/semaphore methodology could be implemented on top of fossil roughly like the following...
files have two flags; lockcontrolled and lockstate
User locks file(s): fossil lock file1 file2 ...
1. Write permissions are removed
2. Lockcontrolled flag is set
3. Lockstate is set.
4. Sync
On check out
1. Files locked by others have write perms removed
On commit
1. Changed locked files cause an error, override with -force
On update
1. Update write permissions per the flags.
2. A locally changed locked file causes a merge failure
On unlock for edit
1. If file not already locked....
2. Update flags, sync
3. Open permissions
Or something like that. I think the closely coupled agressive sync model fostered by fossil makes this very doable.
Matt
-=-
Michael Barrow
Joerg Sonnenberger
> The only problem with binary files is that you cannot merge them.
Even that is not necessarily true. You can't merge binary files like
text files -- sure. But it doesn't mean that for a specific binary
format, a merge algorithm isn't possible. Consider ODF documents for a
moment. A merge program could extract the zip archive, do a *textual*
merge on the XML files and zip the result up again. It works well for
many use cases.
Joerg
Stephan Beal
On Wed, Oct 19, 2011 at 06:42:21PM -0400, Richard Hipp wrote:
> The only problem with binary files is that you cannot merge them.
...moment. A merge program could extract the zip archive, do a *textual*
merge on the XML files and zip the result up again. It works well for
many use cases.
Matt Welland
I get it, but I don't get it. Locks don't make sense in a DVCS. If I'm on a plane (without wifi, of course) and I want to edit a binary file, I'd be hosed because I wouldn't be able to push the lock to the "central" server.
Sure it would help a little. If the files were previously locked then you *know* you are taking a risk making changes that may have to be discarded or tediously manually merged. If you knew you were likely to edit the files on the plane then mark them for edit while you still have Wifi at the airport. Then when your coworker goes to open them she will see that you have taken the edit lock and will know it is best to wait. Simple, clean and workable with fossil thanks to the (brilliant) autosync methodology.
As described in another thread they are similar to a tag but at a file granularity and with the side effect of changing the write permission on the file. Again, lock is too strong a word. Think semaphore. You are just trying to make it easier for people to know who is working on what without a mass of tiresome one line emails such as "don't edit the schematics today!"
What if, like the Fossil main repo for example, there are two central servers?
Tags are synced between the two servers just fine right?
I do like your approach of a wrapper so that crazy lock stuff doesn't destroy the pristine awesomeness of Fossil itself. :-)
Agreed :)
Mike Meyer
Matt Welland <esti...@gmail.com> wrote:
> I sent out a description of how I think light weight "locks" could be
> implemented on top of fossil in a past email. In fact I'm making some good
> progress on implementing what I want in a wrapper around fossil (implement
> locks in addition to some other things). I can look into making the wrapper
> available if anyone is interested.
>
> As has been mentioned Locks are really helpful when managing data that can't
> be automatically merged. However the need is not for draconian control but
> more of a semaphore to prevent accidentally changing a binary file at the
> same time someone else does.
>
> A more than adequate lock/semaphore methodology could be implemented on top
> of fossil roughly like the following...
>
> files have two flags; lockcontrolled and lockstate
>
> User locks file(s): fossil lock file1 file2 ...
> 1. Write permissions are removed
> 2. Lockcontrolled flag is set
> 3. Lockstate is set.
> 4. Sync
Suggestion: If autosync is not enabled, treat this as an
error. Override with -force.
What happens if you find out that someone else has locked the file
during the sync? Do you then revert all the changes you made and fail?
> On check out
> 1. Files locked by others have write perms removed
So the lock is on the file, at all revisions? Are the same file on
different branches considered different files in this case?
> On commit
> 1. Changed locked files cause an error, override with -force
>
> On update
> 1. Update write permissions per the flags.
> 2. A locally changed locked file causes a merge failure
If locks aren't specific to a revision, shouldn't this happen on a
pull (or the pull part of a sync) and not an update?
> On unlock for edit
> 1. If file not already locked....
> 2. Update flags, sync
> 3. Open permissions
>
> Or something like that. I think the closely coupled agressive sync model
> fostered by fossil makes this very doable.
So long as you've got either one central server, or a collection of
very tightly synchronized servers, it should help a lot. Here, tightly
synchronized means "synchronized much more frequently than pushes come
in from developers."
Personally, I still think this is a lot of work to go through to adopt
one tool for a job that other tools are designed to do. Sort of like
building a claw hammer fitting for a screwdriver.
<mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Matt Welland
On Wed, 19 Oct 2011 16:24:17 -0700Suggestion: If autosync is not enabled, treat this as an
Matt Welland <esti...@gmail.com> wrote:
> I sent out a description of how I think light weight "locks" could be
> implemented on top of fossil in a past email. In fact I'm making some good
> progress on implementing what I want in a wrapper around fossil (implement
> locks in addition to some other things). I can look into making the wrapper
> available if anyone is interested.
>
> As has been mentioned Locks are really helpful when managing data that can't
> be automatically merged. However the need is not for draconian control but
> more of a semaphore to prevent accidentally changing a binary file at the
> same time someone else does.
>
> A more than adequate lock/semaphore methodology could be implemented on top
> of fossil roughly like the following...
>
> files have two flags; lockcontrolled and lockstate
>
> User locks file(s): fossil lock file1 file2 ...
> 1. Write permissions are removed
> 2. Lockcontrolled flag is set
> 3. Lockstate is set.
> 4. Sync
error. Override with -force.
Good point. However using the wrapper I take over all calls to fossil and can do what is needed. If building this into fossil itself then the problem is a bit harder.
What happens if you find out that someone else has locked the file
during the sync? Do you then revert all the changes you made and fail?
Terminology is a bit clumsy here. The word lock seems to get us in trouble. This is the model I'm implementing:
term lockcontrolled lockstate writeable
------ -------------- --------- ---------
normal false don't care yes
locked true true no
unlocked true false yes (only by locker)
Going from normal to locked is the dangerous (as in potentially confusing) step. That step should be accompanied by an email for all to do a sync/update before and after.
Going from locked to unlocked for edit is quite safe. The wrapper requests the unlock from the central repo and either gets it or not. Only if it gets the unlock does it open up permissions on the file and notify the user. This is not a distributed action (at least for my wrapper).
> On check outSo the lock is on the file, at all revisions? Are the same file on
> 1. Files locked by others have write perms removed
different branches considered different files in this case?
The way I'm implementing it a path/file will be locked/unlocked for all branches and revisions. Of course this is not a big brother system, users are free to override and screw the other folks on the team. Such moves might be career limiting of course since they have enough information to do the right thing and a record is available as to what really happened.
> On commitIf locks aren't specific to a revision, shouldn't this happen on a
> 1. Changed locked files cause an error, override with -force
>
> On update
> 1. Update write permissions per the flags.
> 2. A locally changed locked file causes a merge failure
pull (or the pull part of a sync) and not an update?
Yes, you are right. Keep in mind that I'm cheating in all this by keeping the lock data in a separate sqlite3 db and can manage the locks on every call to fossil. Doing the right thing as part of fossil itself would be a bit harder I think.
> On unlock for editSo long as you've got either one central server, or a collection of
> 1. If file not already locked....
> 2. Update flags, sync
> 3. Open permissions
>
> Or something like that. I think the closely coupled agressive sync model
> fostered by fossil makes this very doable.
very tightly synchronized servers, it should help a lot. Here, tightly
synchronized means "synchronized much more frequently than pushes come
in from developers."
Yes, very true.
Personally, I still think this is a lot of work to go through to adopt
one tool for a job that other tools are designed to do. Sort of like
building a claw hammer fitting for a screwdriver.
Good point. In fact we are using two systems in parallel for this very reason fossil and another system with rigorous locking. Using the wrapper for locking is really an experiment I'm doing on my own time that may well not pan out.
Jeff Slutter
I would like to be able to handle merging some [proprietary] binary files with my own merge tool, but currently Fossil will refuse to call to gmerge-command when a binary file is involved.
Martin Gagnon
> A couple weeks ago I posted about the possibility of a new configuration setting called something like "allow-binmerge" (default off). If it is enabled, and there is a gmerge-command set, could Fossil call the gmerge-command to resolve a binary merge conflict?
>
> I would like to be able to handle merging some [proprietary] binary files with my own merge tool, but currently Fossil will refuse to call to gmerge-command when a binary file is involved.
>
But for that, you would need a different gmerge-command per file type. (that have a merge tool)
I guess the gmerge command might be specified on command line argument and a new command line argument could be used to force the merge for binary files. This would be easier to implement than adding configuration entries for that.
--
Martin
Jeff Slutter
> On 2011-10-20, at 01:13, Jeff Slutter <je...@slutter.com> wrote:
>
>> A couple weeks ago I posted about the possibility of a new configuration setting called something like "allow-binmerge" (default off). If it is enabled, and there is a gmerge-command set, could Fossil call the gmerge-command to resolve a binary merge conflict?
>>
>> I would like to be able to handle merging some [proprietary] binary files with my own merge tool, but currently Fossil will refuse to call to gmerge-command when a binary file is involved.
>>
> But for that, you would need a different gmerge-command per file type. (that have a merge tool)
I have a merge tool I wrote that can make the determination of what to
do from the file extension. Either it does the work, spawns [and blocks]
another process to do the work, or, in the case of an unmergable, asks
the user to choose from either the original or the merged in version.
>
> I guess the gmerge command might be specified on command line argument and a new command line argument could be used to force the merge for binary files. This would be easier to implement than adding configuration entries for that.
>
I had suggested a gmerge command before, but Richard pointed out that
merging of files might happen outside of a [g]merge, such as when doing
an update or autosyncing.
jos van kesteren
>> Date: Thu, 20 Oct 2011 01:45:30 +0200
>> From: Joerg Sonnenberger <jo...@britannica.bec.de>
>> To: fossil...@lists.fossil-scm.org
>> Subject: Re: [fossil-users] Veracity (was: Fwd: suggestion on fossil)
>> Message-ID: <20111019234...@britannica.bec.de>
>> Content-Type: text/plain; charset=us-ascii
>>
>> On Wed, Oct 19, 2011 at 06:42:21PM -0400, Richard Hipp wrote:
>>
>> text files -- sure. But it doesn't mean that for a specific binary
>> format, a merge algorithm isn't possible. Consider ODF documents for a
>> merge on the XML files and zip the result up again. It works well for
>> many use cases.
>>
>>
Since ODF documents can be unzipped, and their XML contents are text anyway,
why not make a commit program (instead of a merge program) that unzips
the ODF and
stores the XML in the repo ?
Jos van Kesteren.
dexen deVries
> Since ODF documents can be unzipped, and their XML contents are text
> anyway, why not make a commit program (instead of a merge program) that
> unzips the ODF and
> stores the XML in the repo ?
that assumes merging /text/ of XML of ODF documents can be done in a reliable
way. The format seems complex enough to make that error-prone. Same for UML
files.
--
dexen deVries
[[[↓][→]]]
Konstantin Khomoutov
jos van kesteren <josvank...@gmail.com> wrote:
[...]
>>> Even that is not necessarily true. You can't merge binary files
>>> like text files -- sure. But it doesn't mean that for a specific
>>> binary format, a merge algorithm isn't possible. Consider ODF
>>> documents for a moment. A merge program could extract the zip
>>> archive, do a *textual* merge on the XML files and zip the result
>>> up again. It works well for many use cases.
[...]
> Since ODF documents can be unzipped, and their XML contents are text
> anyway, why not make a commit program (instead of a merge program)
> that unzips the ODF and
> stores the XML in the repo ?
Note that there are some problems:
1) Zipping them back is not that trivial [1] which means you have to
use specialized "uncommit" program to properly reassemble such
containers.
2) ODF container stores several files in several directories,
so as soon as you unpacked it, it's not just a single file anymore,
so you have to invent a way to somehow treat the files from this
container as a single entity when they are stored in a DVCS.
(And in some or a parallel thread here someone confirmed Fossil
does only tag commits, not files.)
3) The XML files in ODF containers, while human-readable, are still
autogenerated. The XML format is indeed intended to increase
accessibility of the content, but innocent changes in the document
from the point of view of the user who made them can result in rather
"interesting" changes in the content files. For instance, ODT
(spreadsheets), as far as I know, do not allow you to directly attach
a property to a cell which would indicate that cell has red
background color; instead the editor will create a special style
inculding that color info (unless there's no already existing
matching style) and attach it to that cell.
By this I'm suggesting that diffing contents of two ODF files using
only their unpacked contents could not be that straigforward to
comprehend.
1. http://tanguy.ortolo.eu/blog/article24/
Lluís Batlle i Rossell
>
> > No -- please no locks!
> >
>
>
> Concur. Locks are out-of-band for Fossil. If anybody thinks they really,
> really need locks, I'll be happy to offer them a referral to Veracity.
I think something similar could be said about other fossil features; any feature
is a plus for fossil. You also mentioned some implementation of a checklist.
In a good situation, every developer in a repository will know what will be easy
to merge and what not, and they should know that they have to speak with the
rest of the team to edit that. And then those in the team have to remember that
someone is editing that.
But in a worse case, this system may fail, and some little infrastructure
provided by fossil could be helpful. But, of course, first we should have a
great idea to implement. :)
I don't know how veracity deals with locks, but I think that they should not
only be able to protect against in-branch editions, but also between branches,
when there are future merges planned. With a VCS where people do a lot of
feature-branches (we use fossil this way here), in-branch locks may be of little
help.
Regards,
Lluís.
Mike Meyer
On 2011-10-20, at 01:13, Jeff Slutter <je...@slutter.com> wrote:
> A couple weeks ago I posted about the possibility of a new configuration setting called something like "allow-binmerge" (default off). If it is enabled, and there is a gmerge-command set, could Fossil call the gmerge-command to resolve a binary merge conflict?
>
> I would like to be able to handle merging some [proprietary] binary files with my own merge tool, but currently Fossil will refuse to call to gmerge-command when a binary file is involved.
>
But for that, you would need a different gmerge-command per file type. (that have a merge tool)
Matt Welland
My $0.02 on this subject:
It may be possible to build this into fossil but it is so easy to do outside of fossil I think the added complexity just isn't justified by the limited benefit. Simply write a script that uses "file" on Linux or looks at the extension on Windows and chooses the merge tool accordingly and you are done. Publish the script on the fossil wiki somewhere to make it easy for the next person with this problem.
Dealing with binary files is common but having specialized merge tools (that actually work worth a darn) is very rare. So we can help those with this problem by providing a simple helper script without cluttering up the settings page any more than necessary.
> file thumbnail
thumbnail: PNG image data, 128 x 128, 8-bit/color RGBA, non-interlaced
Then again maybe I'm just behind the times and tools to facilitate binary merge are now reliable and common.....