Hi
My concern about this approach is that if you have lots of different types of files to handle, XML, Word, Rational XMI (which is XML
but has a specific merge tool), etc then you would end up having to do lots of jiggering in the merge hooks. Also, the order in
which you tried to identify the files at the point of merge would become significant, for example the case of the XMI file actually
being an XML file means that you would have to ensure that you checked for XMI before XMI. This could get very complex.
I don't see that as particularly clean for a wide uptake system. Would it be possible to provide a default lua hook for merge which
used a lookup table to map the file type to the correct merge facility and an easy way of setting up that merge? Or replace the lua
hook with one which takes an object implementing merge2,merge3 and any other relevent functions for the particular file type?
Joel
rghetta wrote:
On Sat, 2005-05-28 at 09:44 -0500, Glen Ditchfield wrote:
I worry that, when monotone checks for control characters, it is not always
good enough, and too late for a hook to fix things. I would like to have a
hook that sees that the first six bytes of the file are
\320\317\021\340\241\261 and concludes "this is an MS Word file", instead of
a hook that checks the file suffix for eight different case-sensitive
variations of ".doc" and still guesses wrong sometimes.
This is related to Joel Crisp's point in an earlier posting. What is the root
problem? Does monotone just have to spot the binary files, or does it have
to get a more exact idea of each file's type so that it can invoke a
type-specific merge function? ("This is an MS Word file, so merge the
revisions with Word".)
The "binary file" flag just disables monotone internal merging, thus
invoking everytime the lua hooks merge2()/merge3(). Like the
binary_file() hook, you can override them in a monotonerc file.
These hooks get both name and full file content of all to-be-merged
files. If you want to choose the merge program based on file content,
you do it there.
In short, the step to use MS Word to handle .doc files are:
1. redefine the binary_file() hook to mark .doc files as binary (btw,
current hook comparisons *aren't* case sensitive. The hook takes the
filename, converts it to lowercase, and matches on the converted name).
If you're worried that still can miss some ill-named word files, make
"binary" the default and match only on known text files.
2. redefine the merge2()/merge3() to invoke word when the first bytes of
content match.
Note: if we implement the add-time hook, you will have also access to
file content at step 1.
Riccardo
_______________________________________________
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
_______________________________________________
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel