saurabh gupta venit, vidit, dixit 11.03.2009 17:58: > On Wed, Mar 11, 2009 at 9:59 PM, Daniel Barkalow <barkalow@xxxxxxxxxxxx> wrote: >> On Wed, 11 Mar 2009, saurabh gupta wrote: >> >>> On Wed, Mar 11, 2009 at 7:32 PM, Johannes Schindelin >>> <Johannes.Schindelin@xxxxxx> wrote: >>>> Hi, >>>> >>>> On Wed, 11 Mar 2009, saurabh gupta wrote: >>>> >>>>> What I think is to implement file formats other than text like that >>>>> written on wiki i.e. latex, xml, or even any database file (db file). >>>>> Another idea (although it can be weired also) is to implement the new >>>>> file formats in the plug-in formats. For example, to incorporate the >>>>> merger engine for a new file format, a plug-in is created and can be >>>>> integrated with the present merger in the git. However, I am not sure >>>>> how much valid is this idea to make the present merger in git to be >>>>> compatible with the plug-ins for enabling newer file formats. >>>> I am not sure that a plugin structure is needed. Take, for example, three >>>> different .xml based formats: OpenOffice documents, .svg files and Ant >>>> build.xml files. They need very different user interfaces. >>> okay. In that case, if they have a different user interfaces then >>> separate plug-in would be needed for each of these. May be this will >>> get more messy. >> One thing that I think would be good whenever possible is to have the >> merge program generate a file in the same format which is easily >> recognizable as having conflict markers. For example, I think it should be >> possible to show conflicts in the text of office documents by having >> styles for each side of the merge, and show each side's content in the >> appropriate style. Then the user opens the document with their choice of >> office software, finds the things in the conflict styles, and decides what >> the result should be. > Well, I think this is what which is done in case of normal text files > also. The conflicts put the markers in the file to indicate the > changes and the modification part. However, in the case of OO > documents, we have to change the content for the xml file and when it > is opened in the office software, the user will get the modified > contents. OO already knows versioned documents and recording of changes. It can even merge documents which are different modifications of the same base document (assuming all authors used recording of changes) and compare possibly unrelated documents, merging them interactively. At least OO 3 can do that. So I guess for OO one mostly has to figure out how to call that stuff from the command line. Heck, even MS Office can do that. Remember those docs with recorded changes, where published documents contained the deletions as well as the deleted passages? Michael -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
