On Thu, Mar 12, 2009 at 11:30 PM, [off-list ref] wrote:
quoted
On Thu, 12 Mar 2009, saurabh gupta wrote:
quoted
=>Merging of two xml files
=> existing merge driver (like xdl) is called which marks the
conflicts points just like a normal text file.
=> the conflicted file can be read through a text terminal and
conflicted lines can be seen.
=> suppose the xml file is from the domain of OO document. Then, a
merge helper for OO xml type file is called which takes input as the
conflicted file produced by xdl driver.
=> The merge helper creates a new file or changes the input file to
make it a valid xml file so that it can be opened in OpenOffice and
user can see the markers like "====" or "<<<<<" in an appropriate
manner and can resolve the file manually.
with XML files it's possible to be symanticly identical, but not identical
as far as a text merge driver is concerned.
<SNIPB>
you are right. For xml merging, what I am thinking is to create the
algorithm based on the document object model. Inside, any tag, all tags are
compared only in terms of content and not in order. But again, this ordering
option can be given to the user. If the user wants order to matter, then a
conflict will be resulted if order mismatches.
right.
But other issue is regarding the display of conflict markers. Either
conflict markers should be put in xml format or like text merger. This is
the main project idea for GSoC 2009.
this may need to be a configurable option, but I suspect that we could get
away with always using something in XML format. exactly what the markers
are needs to be configurable (the markers for OO will not be the same as
for SVG for example)
building a library of 'this works especially well for this app' markers is
something that needs to be started as part of the GSOC project, but
possibly only far enough to show a couple of examples and have confidence
that the tool is configurable enough.
David Lang
On Fri, Mar 13, 2009 at 12:23 AM, [off-list ref] wrote:
On Thu, 12 Mar 2009, saurabh gupta wrote:
quoted
On Thu, Mar 12, 2009 at 11:30 PM, [off-list ref] wrote:
quoted
On Thu, 12 Mar 2009, saurabh gupta wrote:
quoted
=>Merging of two xml files
=> existing merge driver (like xdl) is called which marks the
conflicts points just like a normal text file.
=> the conflicted file can be read through a text terminal and
conflicted lines can be seen.
=> suppose the xml file is from the domain of OO document. Then, a
merge helper for OO xml type file is called which takes input as the
conflicted file produced by xdl driver.
=> The merge helper creates a new file or changes the input file to
make it a valid xml file so that it can be opened in OpenOffice and
user can see the markers like "====" or "<<<<<" in an appropriate
manner and can resolve the file manually.
with XML files it's possible to be symanticly identical, but not
identical
as far as a text merge driver is concerned.
<SNIPB>
quoted
you are right. For xml merging, what I am thinking is to create the
algorithm based on the document object model. Inside, any tag, all tags
are
compared only in terms of content and not in order. But again, this
ordering
option can be given to the user. If the user wants order to matter, then a
conflict will be resulted if order mismatches.
right.
quoted
But other issue is regarding the display of conflict markers. Either
conflict markers should be put in xml format or like text merger. This is
the main project idea for GSoC 2009.
this may need to be a configurable option, but I suspect that we could get
away with always using something in XML format. exactly what the markers are
needs to be configurable (the markers for OO will not be the same as for SVG
for example)
yeah.
building a library of 'this works especially well for this app' markers is
something that needs to be started as part of the GSOC project, but possibly
only far enough to show a couple of examples and have confidence that the
tool is configurable enough.
I think picking up some formats and then building libraries above that
is needed. In some sense, I talked about the plug-in architecture
also. Can;t it be possible that for different applications (like OO or
SVG), different merge helper plugins are created which can be
integrated with it. Or speaking in other words, instead of plug-ins
now, libraries for merge helpers for different applications are
created.
--
Saurabh Gupta
Senior,
NSIT,New Delhi, India
On Fri, Mar 13, 2009 at 12:23 AM, [off-list ref] wrote:
quoted
On Thu, 12 Mar 2009, saurabh gupta wrote:
quoted
On Thu, Mar 12, 2009 at 11:30 PM, [off-list ref] wrote:
quoted
On Thu, 12 Mar 2009, saurabh gupta wrote:
quoted
=>Merging of two xml files
=> existing merge driver (like xdl) is called which marks the
conflicts points just like a normal text file.
=> the conflicted file can be read through a text terminal and
conflicted lines can be seen.
=> suppose the xml file is from the domain of OO document. Then, a
merge helper for OO xml type file is called which takes input as the
conflicted file produced by xdl driver.
=> The merge helper creates a new file or changes the input file to
make it a valid xml file so that it can be opened in OpenOffice and
user can see the markers like "====" or "<<<<<" in an appropriate
manner and can resolve the file manually.
with XML files it's possible to be symanticly identical, but not
identical
as far as a text merge driver is concerned.
<SNIPB>
quoted
you are right. For xml merging, what I am thinking is to create the
algorithm based on the document object model. Inside, any tag, all tags
are
compared only in terms of content and not in order. But again, this
ordering
option can be given to the user. If the user wants order to matter, then a
conflict will be resulted if order mismatches.
right.
quoted
But other issue is regarding the display of conflict markers. Either
conflict markers should be put in xml format or like text merger. This is
the main project idea for GSoC 2009.
this may need to be a configurable option, but I suspect that we could get
away with always using something in XML format. exactly what the markers are
needs to be configurable (the markers for OO will not be the same as for SVG
for example)
yeah.
quoted
building a library of 'this works especially well for this app' markers is
something that needs to be started as part of the GSOC project, but possibly
only far enough to show a couple of examples and have confidence that the
tool is configurable enough.
I think picking up some formats and then building libraries above that
is needed. In some sense, I talked about the plug-in architecture
also. Can;t it be possible that for different applications (like OO or
SVG), different merge helper plugins are created which can be
integrated with it. Or speaking in other words, instead of plug-ins
now, libraries for merge helpers for different applications are
created.
defining terminology that was mentioned before
merge drivers are run by git to do the merges and create the conflict
markers. git already has a 'plug-in architecture' for these drivers (you
can define file types and tell git to use a particular merge driver for
this file type)
merge helpers are run by the users if there is a conflict and make use of
the markers. depending on what you end up using for conflict markers, you
may not need to write a merge helper (for OO, if your conflict markers are
good enough you can use OO to resolve conflicts easily, no need for a new
tool)
with this terminology, you can't do merge helpers without doing the merge
drivers first (what does the helper look for as an indicator of a
conflict?)
I believe that there is a lot of potential for a configurable merge driver
to support many similar formats.
using the example of XML-based files, configurable options could include
1. is the file stored compressed or not
2. does the order of the tags matter
3. does whitespace matter
note: #2 and #3 may boil down to 'is this a document with XML markup, or
are the XML tags the primary content'
4. how is the conflict marked
4a. wrap the conflicting tags in a set of tags that look like _
4b. if the conflict is in the content, not the tags, modify it similar to
what we do with text today.
note: this still requires the new driver to decide if there is a
conflict or not
4c. other (potentially including calling out to other code for more
drastic restructuring)
with a merge driver along these lines you can handle many different types
of XML documents.
with SVG you may be able to put the offending tags in different layers
with OO you may be able to put in tags that indicate a merge conflict in a
way that OO will directly handle
etc.
in many cases you may not even need to create a merge helper or library
for other software you use. you just need to figure out what sort of
manipulation would need to be done to to file to mark the conflict in a
way that existing applications can understand.
David Lang
On Fri, Mar 13, 2009 at 12:59 AM, [off-list ref] wrote:
On Fri, 13 Mar 2009, saurabh gupta wrote:
defining terminology that was mentioned before
merge drivers are run by git to do the merges and create the conflict
markers. git already has a 'plug-in architecture' for these drivers (you can
define file types and tell git to use a particular merge driver for this
file type)
merge helpers are run by the users if there is a conflict and make use of
the markers. depending on what you end up using for conflict markers, you
may not need to write a merge helper (for OO, if your conflict markers are
good enough you can use OO to resolve conflicts easily, no need for a new
tool)
with this terminology, you can't do merge helpers without doing the merge
drivers first (what does the helper look for as an indicator of a conflict?)
I believe that there is a lot of potential for a configurable merge driver
to support many similar formats.
using the example of XML-based files, configurable options could include
1. is the file stored compressed or not
2. does the order of the tags matter
3. does whitespace matter
note: #2 and #3 may boil down to 'is this a document with XML markup, or
are the XML tags the primary content'
4. how is the conflict marked
4a. wrap the conflicting tags in a set of tags that look like _
4b. if the conflict is in the content, not the tags, modify it similar to
what we do with text today.
note: this still requires the new driver to decide if there is a conflict
or not
4c. other (potentially including calling out to other code for more drastic
restructuring)
with a merge driver along these lines you can handle many different types of
XML documents.
with SVG you may be able to put the offending tags in different layers
with OO you may be able to put in tags that indicate a merge conflict in a
way that OO will directly handle
etc.
in many cases you may not even need to create a merge helper or library for
other software you use. you just need to figure out what sort of
manipulation would need to be done to to file to mark the conflict in a way
that existing applications can understand.
Very well described, David. I agree with you and providing these merge
options to the user, merge drivers can do the work and mark the
conflicts according to the option. The work to do is to modify the
merge driver. I think in this way, even people who have only a
terminal can also gain from it. They can choose the apt option to see
the conflict markers in their way. So, the aim is to make merge driver
configurable and create the merged/conflicted file according to the
options.
--
Saurabh Gupta
Senior,
NSIT,New Delhi, India
Very well described, David. I agree with you and providing these merge
options to the user, merge drivers can do the work and mark the
conflicts according to the option. The work to do is to modify the
merge driver. I think in this way, even people who have only a
terminal can also gain from it. They can choose the apt option to see
the conflict markers in their way. So, the aim is to make merge driver
configurable and create the merged/conflicted file according to the
options.
for the GSOC I suspect that the right thing to do is the define one or
more merge drivers to create, and list what applications are going to be
used for testing these merges.
you and the mentor can decide what is a reasonable amount of work.
it may be just doing an XML merge driver is a summer's worth of work, or
it may be that it's not really enough and you should try to do another one
or two.
it also may be that there is a lot of overlap between different merge
drivers, and once you have the XML driver the others become fairly trivial
to do. (I'm thinking the config file examples I posted earlier in the
thread)
David Lang
On Fri, Mar 13, 2009 at 1:29 AM, [off-list ref] wrote:
On Fri, 13 Mar 2009, saurabh gupta wrote:
quoted
Very well described, David. I agree with you and providing these merge
options to the user, merge drivers can do the work and mark the
conflicts according to the option. The work to do is to modify the
merge driver. I think in this way, even people who have only a
terminal can also gain from it. They can choose the apt option to see
the conflict markers in their way. So, the aim is to make merge driver
configurable and create the merged/conflicted file according to the
options.
for the GSOC I suspect that the right thing to do is the define one or more
merge drivers to create, and list what applications are going to be used for
testing these merges.
you and the mentor can decide what is a reasonable amount of work.
I will very glad to hear about this thing from the mentor (Johannes
Schindelin, according to wiki). I will try to plan out the things in a
proper way to carry out this project if I get a chance to work on this
for GSoC 2009.
it may be just doing an XML merge driver is a summer's worth of work, or it
may be that it's not really enough and you should try to do another one or
two.
it also may be that there is a lot of overlap between different merge
drivers, and once you have the XML driver the others become fairly trivial
to do. (I'm thinking the config file examples I posted earlier in the
thread)
with the options given to the user, one can handle the config files
also where order doesn't matter and also the whitespaces problem can
also be handled in the similar way.
--
Saurabh Gupta
Senior,
NSIT,New Delhi, India
On Fri, Mar 13, 2009 at 1:29 AM, [off-list ref] wrote:
quoted
On Fri, 13 Mar 2009, saurabh gupta wrote:
quoted
Very well described, David. I agree with you and providing these merge
options to the user, merge drivers can do the work and mark the
conflicts according to the option. The work to do is to modify the
merge driver. I think in this way, even people who have only a
terminal can also gain from it. They can choose the apt option to see
the conflict markers in their way. So, the aim is to make merge driver
configurable and create the merged/conflicted file according to the
options.
for the GSOC I suspect that the right thing to do is the define one or more
merge drivers to create, and list what applications are going to be used for
testing these merges.
you and the mentor can decide what is a reasonable amount of work.
I will very glad to hear about this thing from the mentor (Johannes
Schindelin, according to wiki). I will try to plan out the things in a
proper way to carry out this project if I get a chance to work on this
for GSoC 2009.
quoted
it may be just doing an XML merge driver is a summer's worth of work, or it
may be that it's not really enough and you should try to do another one or
two.
it also may be that there is a lot of overlap between different merge
drivers, and once you have the XML driver the others become fairly trivial
to do. (I'm thinking the config file examples I posted earlier in the
thread)
with the options given to the user, one can handle the config files
also where order doesn't matter and also the whitespaces problem can
also be handled in the similar way.
when I am mentioning config files here I'm thinking of ones that don't use
XML (such as the git config file)
a 'paragraph' merge driver could also help with things like a maintainers
file where the order of the paragaphs doesn't matter, just the content
inside each one.
that's very similar to re-ordering XML tags, but with a slightly different
syntax
David Lang
On Fri, Mar 13, 2009 at 2:15 AM, [off-list ref] wrote:
when I am mentioning config files here I'm thinking of ones that don't use
XML (such as the git config file)
a 'paragraph' merge driver could also help with things like a maintainers
file where the order of the paragaphs doesn't matter, just the content
inside each one.
that's very similar to re-ordering XML tags, but with a slightly different
syntax
yes, in that case, I think we can modify the existing text merge
driver somewhat and provide these configuration options to the user.
User can choose the option to configure the merge operation.
--
Saurabh Gupta
Senior,
NSIT,New Delhi, India
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:46:25
Hi,
On Fri, 13 Mar 2009, saurabh gupta wrote:
On Fri, Mar 13, 2009 at 1:29 AM, [off-list ref] wrote:
quoted
On Fri, 13 Mar 2009, saurabh gupta wrote:
quoted
Very well described, David. I agree with you and providing these
merge options to the user, merge drivers can do the work and mark the
conflicts according to the option. The work to do is to modify the
merge driver. I think in this way, even people who have only a
terminal can also gain from it. They can choose the apt option to see
the conflict markers in their way. So, the aim is to make merge
driver configurable and create the merged/conflicted file according
to the options.
for the GSOC I suspect that the right thing to do is the define one or
more merge drivers to create, and list what applications are going to
be used for testing these merges.
you and the mentor can decide what is a reasonable amount of work.
I will very glad to hear about this thing from the mentor (Johannes
Schindelin, according to wiki). I will try to plan out the things in a
proper way to carry out this project if I get a chance to work on this
for GSoC 2009.
Well, now that we have been accepted as an organization, we can move
forward with this idea!
My main concern is that we define early on what should be the user
interface, preferably with a quick sketch.
The technical details, we can hash them out later, I have no doubt that
with the help of the complete Git community, we can overcome almost every
problem handling XML data or some such.
quoted
it may be just doing an XML merge driver is a summer's worth of work,
or it may be that it's not really enough and you should try to do
another one or two.
it also may be that there is a lot of overlap between different merge
drivers, and once you have the XML driver the others become fairly
trivial to do. (I'm thinking the config file examples I posted earlier
in the thread)
with the options given to the user, one can handle the config files
also where order doesn't matter and also the whitespaces problem can
also be handled in the similar way.
In my humble opinion, we should focus on the data types we want to be
able to support at the end of the summer first.
For example, if we decide that OOXML is a must (as it is a proper
standard, and many people will benefit from it), we will most likely end
up in having to write a merge _driver_ (to handle those .zip files), _and_
a merge _helper_, although we can avoid writing our own GUI, as we can
create an OOXML that has its own version of conflict markers.
If we decide that SVG is something we want to support by the end of the
summer, then we can probably avoid writing a merge _driver_, as plain text
is handled reasonably well in Git. OTOH it could turn out that there are
_real_ conflicts in overlapping tag ids, and it would still be easier to
write a merge driver, too.
IOW the details are not as important as
- knowing what data types we want to support _at the least_, and what data
types we keep for the free skate,
- a clear picture of the user interface we want to be able to provide,
- a timeline (weekly milestones should be fine, I guess) what should be
achieved when, and
- being flexible in how to support that (IOW if a merge driver appears
unnecessary first, but necessary later, we should be able to fit that
into both the design and the timeline).
How does that sound?
Ciao,
Dscho
On Fri, Mar 13, 2009 at 1:29 AM, [off-list ref] wrote:
quoted
On Fri, 13 Mar 2009, saurabh gupta wrote:
it may be just doing an XML merge driver is a summer's worth of work,
or it may be that it's not really enough and you should try to do
another one or two.
it also may be that there is a lot of overlap between different merge
drivers, and once you have the XML driver the others become fairly
trivial to do. (I'm thinking the config file examples I posted earlier
in the thread)
with the options given to the user, one can handle the config files
also where order doesn't matter and also the whitespaces problem can
also be handled in the similar way.
In my humble opinion, we should focus on the data types we want to be
able to support at the end of the summer first.
For example, if we decide that OOXML is a must (as it is a proper
standard, and many people will benefit from it), we will most likely end
up in having to write a merge _driver_ (to handle those .zip files), _and_
a merge _helper_, although we can avoid writing our own GUI, as we can
create an OOXML that has its own version of conflict markers.
do you mean OOXML (the microsoft format) or ODF (the open office format)?
If we decide that SVG is something we want to support by the end of the
summer, then we can probably avoid writing a merge _driver_, as plain text
is handled reasonably well in Git. OTOH it could turn out that there are
_real_ conflicts in overlapping tag ids, and it would still be easier to
write a merge driver, too.
IOW the details are not as important as
- knowing what data types we want to support _at the least_, and what data
types we keep for the free skate,
- a clear picture of the user interface we want to be able to provide,
- a timeline (weekly milestones should be fine, I guess) what should be
achieved when, and
- being flexible in how to support that (IOW if a merge driver appears
unnecessary first, but necessary later, we should be able to fit that
into both the design and the timeline).
it's up to the student, but I suspect that the best approach would be to
start with defining a merge driver to handle XML (with a minimum set of
capabilities, and additional optional ones), and go from there.
David Lang
How does that sound?
Ciao,
Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:46:25
Hi,
On Wed, 18 Mar 2009, david@lang.hm wrote:
On Thu, 19 Mar 2009, Johannes Schindelin wrote:
quoted
On Fri, 13 Mar 2009, saurabh gupta wrote:
quoted
On Fri, Mar 13, 2009 at 1:29 AM, [off-list ref] wrote:
quoted
On Fri, 13 Mar 2009, saurabh gupta wrote:
it may be just doing an XML merge driver is a summer's worth of
work, or it may be that it's not really enough and you should try
to do another one or two.
it also may be that there is a lot of overlap between different
merge drivers, and once you have the XML driver the others become
fairly trivial to do. (I'm thinking the config file examples I
posted earlier in the thread)
with the options given to the user, one can handle the config files
also where order doesn't matter and also the whitespaces problem can
also be handled in the similar way.
In my humble opinion, we should focus on the data types we want to be
able to support at the end of the summer first.
For example, if we decide that OOXML is a must (as it is a proper
standard, and many people will benefit from it), we will most likely
end up in having to write a merge _driver_ (to handle those .zip
files), _and_ a merge _helper_, although we can avoid writing our own
GUI, as we can create an OOXML that has its own version of conflict
markers.
do you mean OOXML (the microsoft format) or ODF (the open office
format)?
Oops.
EOVERLOAD
quoted
If we decide that SVG is something we want to support by the end of
the summer, then we can probably avoid writing a merge _driver_, as
plain text is handled reasonably well in Git. OTOH it could turn out
that there are _real_ conflicts in overlapping tag ids, and it would
still be easier to write a merge driver, too.
IOW the details are not as important as
- knowing what data types we want to support _at the least_, and what
data types we keep for the free skate,
- a clear picture of the user interface we want to be able to provide,
- a timeline (weekly milestones should be fine, I guess) what should
be achieved when, and
- being flexible in how to support that (IOW if a merge driver appears
unnecessary first, but necessary later, we should be able to fit
that into both the design and the timeline).
it's up to the student, but I suspect that the best approach would be to
start with defining a merge driver to handle XML (with a minimum set of
capabilities, and additional optional ones), and go from there.
Well, the thing is: if the student decides to have a go at an XML driver
first and foremost, then I'll just flatly refuse to mentor that. Because
I sincerely believe that this project is best designed from top to bottom,
not the other way round.
After all, the project is based on a user's request, not just a
playthingie for an XML enthusiast (if such a thing exists).
Ciao,
Dscho
On Wed, Mar 18, 2009 at 7:16 PM, Johannes Schindelin
[off-list ref] wrote:
In my humble opinion, we should focus on the data types we want to be
able to support at the end of the summer first.
my 2 cents don't support xml, support sgml start at the least common
denominator and refine from there.
--
Caleb Cushing
http://xenoterracide.blogspot.com
In my humble opinion, we should focus on the data types we want to be
able to support at the end of the summer first.
For example, if we decide that OOXML is a must (as it is a proper
standard, and many people will benefit from it), we will most likely
end up in having to write a merge _driver_ (to handle those .zip
files), _and_ a merge _helper_, although we can avoid writing our own
GUI, as we can create an OOXML that has its own version of conflict
markers.
do you mean OOXML (the microsoft format) or ODF (the open office
format)?
Oops.
EOVERLOAD
it happens.
quoted
quoted
If we decide that SVG is something we want to support by the end of
the summer, then we can probably avoid writing a merge _driver_, as
plain text is handled reasonably well in Git. OTOH it could turn out
that there are _real_ conflicts in overlapping tag ids, and it would
still be easier to write a merge driver, too.
IOW the details are not as important as
- knowing what data types we want to support _at the least_, and what
data types we keep for the free skate,
- a clear picture of the user interface we want to be able to provide,
- a timeline (weekly milestones should be fine, I guess) what should
be achieved when, and
- being flexible in how to support that (IOW if a merge driver appears
unnecessary first, but necessary later, we should be able to fit
that into both the design and the timeline).
it's up to the student, but I suspect that the best approach would be to
start with defining a merge driver to handle XML (with a minimum set of
capabilities, and additional optional ones), and go from there.
Well, the thing is: if the student decides to have a go at an XML driver
first and foremost, then I'll just flatly refuse to mentor that. Because
I sincerely believe that this project is best designed from top to bottom,
not the other way round.
After all, the project is based on a user's request, not just a
playthingie for an XML enthusiast (if such a thing exists).
all three formats mentioned here (OOXML, ODF, SVG) are XML-based formats
and a single flexible XML merge driver could potentially handle all three
(as well as other formats). for that matter, the ODF specs cover multiple
types of data, and I suspect that appropriate conflict markers for text
could well end up being different than the ones for spreadsheets.
that's not a 'plaything for an XML entusiast', it's making the tool
slightly more general than it would need to be for any one of these
formats to let it handle all of them.
but I'm not a mentor or a student, just an interested user.
David Lang
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:46:25
Hi,
On Thu, 19 Mar 2009, david@lang.hm wrote:
all three formats mentioned here (OOXML, ODF, SVG) are XML-based formats
and a single flexible XML merge driver could potentially handle all
three (as well as other formats). for that matter, the ODF specs cover
multiple types of data, and I suspect that appropriate conflict markers
for text could well end up being different than the ones for
spreadsheets.
You are misunderstanding me.
The fact that all three are XML based has nothing to do with the _real_
goal of the project.
IOW a user trying to 3-way-merge ODF files could not care less if the
underlying technical details involve having an extra merge driver for XML
files or not.
The user cares about the ease of use, about the user interface. That is
what I want to focus on.
And if we end up with a beautiful XML merge driver at the end of the
summer that nobody uses, I will be not only a little disappointed.
So let's look at the _nature_ of the data at hand, i.e. text, marked-up
text, images (we could include UML, which is also XML-based, and where the
XML merge driver is as relevant for the user experience as for the
others), and how to make it _easy_ to resolve merge conflicts there.
Ciao,
Dscho
all three formats mentioned here (OOXML, ODF, SVG) are XML-based formats
and a single flexible XML merge driver could potentially handle all
three (as well as other formats). for that matter, the ODF specs cover
multiple types of data, and I suspect that appropriate conflict markers
for text could well end up being different than the ones for
spreadsheets.
You are misunderstanding me.
The fact that all three are XML based has nothing to do with the _real_
goal of the project.
IOW a user trying to 3-way-merge ODF files could not care less if the
underlying technical details involve having an extra merge driver for XML
files or not.
The user cares about the ease of use, about the user interface. That is
what I want to focus on.
And if we end up with a beautiful XML merge driver at the end of the
summer that nobody uses, I will be not only a little disappointed.
So let's look at the _nature_ of the data at hand, i.e. text, marked-up
text, images (we could include UML, which is also XML-based, and where the
XML merge driver is as relevant for the user experience as for the
others), and how to make it _easy_ to resolve merge conflicts there.
but don't you want to be able to auto-merge as much as possible before you
have to go to _any_ user interaction? (the best user interface is one you
don't need to use)
it's only after the merge drive decides that it can't do the merge that
you would have to move on to manually resolving conflicts.
when you _do_ move on to resolving conflicts, it's not a good approach to
write a GUI tool to deal with each datatype (git does not need it's own
ODF text document editory, spreadsheed editor, graphics editor, etc). it
may end up being nessasary for some document types, but that's a last
resort. it's far better if the conflict markers can be inserted in such a
way that the normal tools for dealing with that file type can be used.
git doesn't provide (or mandate) what editor is used to resolve conflicts
in text files today, it should not do so for other file types either
(again, except as a last resort)
the only way to start from the GUI and not create a merge driver first is
to either have a custom GUI that accepts files 'corrupted' with the
existing conflict markers, or work on a GUI that works with both of the
sources as entire files, with no conflict markers or assistance from git.
David Lang
Hi all,
Sorry for replying so late as I was busy in my college's mid-semester exams :-|
On Thu, Mar 19, 2009 at 4:46 AM, Johannes Schindelin
[off-list ref] wrote:
Hi,
On Fri, 13 Mar 2009, saurabh gupta wrote:
quoted
On Fri, Mar 13, 2009 at 1:29 AM, [off-list ref] wrote:
quoted
On Fri, 13 Mar 2009, saurabh gupta wrote:
quoted
Very well described, David. I agree with you and providing these
merge options to the user, merge drivers can do the work and mark the
conflicts according to the option. The work to do is to modify the
merge driver. I think in this way, even people who have only a
terminal can also gain from it. They can choose the apt option to see
the conflict markers in their way. So, the aim is to make merge
driver configurable and create the merged/conflicted file according
to the options.
for the GSOC I suspect that the right thing to do is the define one or
more merge drivers to create, and list what applications are going to
be used for testing these merges.
you and the mentor can decide what is a reasonable amount of work.
I will very glad to hear about this thing from the mentor (Johannes
Schindelin, according to wiki). I will try to plan out the things in a
proper way to carry out this project if I get a chance to work on this
for GSoC 2009.
Well, now that we have been accepted as an organization, we can move
forward with this idea!
Congrats for getting accepted in GSoC 2009.
My main concern is that we define early on what should be the user
interface, preferably with a quick sketch.
The technical details, we can hash them out later, I have no doubt that
with the help of the complete Git community, we can overcome almost every
problem handling XML data or some such.
quoted
quoted
it may be just doing an XML merge driver is a summer's worth of work,
or it may be that it's not really enough and you should try to do
another one or two.
it also may be that there is a lot of overlap between different merge
drivers, and once you have the XML driver the others become fairly
trivial to do. (I'm thinking the config file examples I posted earlier
in the thread)
with the options given to the user, one can handle the config files
also where order doesn't matter and also the whitespaces problem can
also be handled in the similar way.
In my humble opinion, we should focus on the data types we want to be
able to support at the end of the summer first.
For example, if we decide that OOXML is a must (as it is a proper
standard, and many people will benefit from it), we will most likely end
up in having to write a merge _driver_ (to handle those .zip files), _and_
a merge _helper_, although we can avoid writing our own GUI, as we can
create an OOXML that has its own version of conflict markers.
Well, for ODF type document, we can write a merge driver which will
change the xml file in an appropriate way that OO can understand it
and the user can see the merge result/conflict in a comfortable way.
As described by Junio, in this case, a dedicated merge helper is not
needed as OO can parse the markers made by merge-driver and provide
the user to resolve the conflict and register the changes to index.
If we decide that SVG is something we want to support by the end of the
summer, then we can probably avoid writing a merge _driver_, as plain text
is handled reasonably well in Git. OTOH it could turn out that there are
_real_ conflicts in overlapping tag ids, and it would still be easier to
write a merge driver, too.
IOW the details are not as important as
- knowing what data types we want to support _at the least_, and what data
types we keep for the free skate,
As of now, how about going for XML files. For this summer, we can go
for XML files and latex files can be handled later.
- a clear picture of the user interface we want to be able to provide,
In my opinion, we have following things to do:
=> while merging an ODF document, merge-driver will merge the file at
file level. If changes don't overlap, then it returns the result with
a success. For example, if the file is changed only on one side, then
the driver will simply add the new content.
=> If conflicts appear, then the merge driver will put the markers in
an appropriate manner which the end-user application (e.g. open
office) can understand and show the user. For example, the XML file of
that ODF document will be modified and OO can show it to user in its
way. We will have to study about the OO style of version marking.
Another method is to implement the marker style in our own way. For
example, to show any marker, the XML file is modified so that user can
see markers like ">>>> " or "====" in openoffice....In this case, we
will have to just change the xml content in this way.
- a timeline (weekly milestones should be fine, I guess) what should be
achieved when, and
Timeline can be decided once we reach some conclusion and the work
which needs to be done become clear to us.
- being flexible in how to support that (IOW if a merge driver appears
unnecessary first, but necessary later, we should be able to fit that
into both the design and the timeline).
How does that sound?
Ciao,
Dscho
On Thu, Mar 19, 2009 at 6:13 AM, Johannes Schindelin
[off-list ref] wrote:
Hi,
On Wed, 18 Mar 2009, david@lang.hm wrote:
quoted
On Thu, 19 Mar 2009, Johannes Schindelin wrote:
quoted
On Fri, 13 Mar 2009, saurabh gupta wrote:
quoted
On Fri, Mar 13, 2009 at 1:29 AM, [off-list ref] wrote:
quoted
On Fri, 13 Mar 2009, saurabh gupta wrote:
it may be just doing an XML merge driver is a summer's worth of
work, or it may be that it's not really enough and you should try
to do another one or two.
it also may be that there is a lot of overlap between different
merge drivers, and once you have the XML driver the others become
fairly trivial to do. (I'm thinking the config file examples I
posted earlier in the thread)
with the options given to the user, one can handle the config files
also where order doesn't matter and also the whitespaces problem can
also be handled in the similar way.
In my humble opinion, we should focus on the data types we want to be
able to support at the end of the summer first.
For example, if we decide that OOXML is a must (as it is a proper
standard, and many people will benefit from it), we will most likely
end up in having to write a merge _driver_ (to handle those .zip
files), _and_ a merge _helper_, although we can avoid writing our own
GUI, as we can create an OOXML that has its own version of conflict
markers.
do you mean OOXML (the microsoft format) or ODF (the open office
format)?
Oops.
EOVERLOAD
quoted
quoted
If we decide that SVG is something we want to support by the end of
the summer, then we can probably avoid writing a merge _driver_, as
plain text is handled reasonably well in Git. OTOH it could turn out
that there are _real_ conflicts in overlapping tag ids, and it would
still be easier to write a merge driver, too.
IOW the details are not as important as
- knowing what data types we want to support _at the least_, and what
data types we keep for the free skate,
- a clear picture of the user interface we want to be able to provide,
- a timeline (weekly milestones should be fine, I guess) what should
be achieved when, and
- being flexible in how to support that (IOW if a merge driver appears
unnecessary first, but necessary later, we should be able to fit
that into both the design and the timeline).
it's up to the student, but I suspect that the best approach would be to
start with defining a merge driver to handle XML (with a minimum set of
capabilities, and additional optional ones), and go from there.
Well, the thing is: if the student decides to have a go at an XML driver
first and foremost, then I'll just flatly refuse to mentor that. Because
I sincerely believe that this project is best designed from top to bottom,
not the other way round.
After all, the project is based on a user's request, not just a
playthingie for an XML enthusiast (if such a thing exists).
I do agree with you that unless an end user get to see the conflict
result in an appropriate manner, there is no use of having an xml
merger. But, once we decide as what will be the end file type which we
will aim this summer, we can then start working whether its about
making a GUI first, or creating a merge driver first.
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:46:25
Hi,
On Fri, 20 Mar 2009, saurabh gupta wrote:
On Thu, Mar 19, 2009 at 4:46 AM, Johannes Schindelin
[off-list ref] wrote:
quoted
For example, if we decide that OOXML is a must (as it is a proper
standard, and many people will benefit from it), we will most likely
end up in having to write a merge _driver_ (to handle those .zip
files), _and_ a merge _helper_, although we can avoid writing our own
GUI, as we can create an OOXML that has its own version of conflict
markers.
Well, for ODF type document, we can write a merge driver which will
change the xml file in an appropriate way that OO can understand it and
the user can see the merge result/conflict in a comfortable way. As
described by Junio, in this case, a dedicated merge helper is not needed
as OO can parse the markers made by merge-driver and provide the user to
resolve the conflict and register the changes to index.
There is also the idea that OOffice has building blocks in place to help
resolving merge conflicts. For a successful application, you will have to
show that you researched that option, and describe how well/badly it fits
with the goal of the project.
quoted
- knowing what data types we want to support _at the least_, and what
data types we keep for the free skate,
As of now, how about going for XML files. For this summer, we can go for
XML files and latex files can be handled later.
If your goal is just XML files (without any more specific goal, like ODF
or SVG), I am afraid that I think that project is not worth 4500 dollar
from Google's pocket. I mean, we are not talking peanuts here.
quoted
- a clear picture of the user interface we want to be able to provide,
In my opinion, we have following things to do:
=> while merging an ODF document, merge-driver will merge the file at
file level. If changes don't overlap, then it returns the result with
a success. For example, if the file is changed only on one side, then
the driver will simply add the new content.
=> If conflicts appear, then the merge driver will put the markers in
an appropriate manner which the end-user application (e.g. open
office) can understand and show the user. For example, the XML file of
that ODF document will be modified and OO can show it to user in its
way. We will have to study about the OO style of version marking.
Another method is to implement the marker style in our own way. For
example, to show any marker, the XML file is modified so that user can
see markers like ">>>> " or "====" in openoffice....In this case, we
will have to just change the xml content in this way.
That is correct, but I would appreciate a bit more definitive research
_before_ the project proposal, as a sign that you are capable of working
out the details of the project.
quoted
- a timeline (weekly milestones should be fine, I guess) what should
be achieved when, and
Timeline can be decided once we reach some conclusion and the work which
needs to be done become clear to us.
Last year, most successful applications detailed a proposed timeline in
their proposal...
Do not get me wrong, I want this project to succeed.
But on the other hand, I feel the obligation to be a bit demanding for the
gracious donation of Google: we _do_ want to have something stunningly
awesome at the end of the summer.
And that means that I have to get the impression from the student proposal
that something like that is at least _possible_.
Ciao,
Dscho
On Thu, Mar 19, 2009 at 4:46 AM, Johannes Schindelin
[off-list ref] wrote:
quoted
For example, if we decide that OOXML is a must (as it is a proper
standard, and many people will benefit from it), we will most likely
end up in having to write a merge _driver_ (to handle those .zip
files), _and_ a merge _helper_, although we can avoid writing our own
GUI, as we can create an OOXML that has its own version of conflict
markers.
Well, for ODF type document, we can write a merge driver which will
change the xml file in an appropriate way that OO can understand it and
the user can see the merge result/conflict in a comfortable way. As
described by Junio, in this case, a dedicated merge helper is not needed
as OO can parse the markers made by merge-driver and provide the user to
resolve the conflict and register the changes to index.
There is also the idea that OOffice has building blocks in place to help
resolving merge conflicts. For a successful application, you will have to
show that you researched that option, and describe how well/badly it fits
with the goal of the project.
true, although for the 'simple case' of an ODF text file you can use
text strings exactly the same way you do with a text file. the difference
is that when inserting the two versions of things into the 'conflict'
version of the ODF file you need to make sure that you include the
complete open/close set of tags in each version.
for example if file 1 has
<tag1 param='1'>
text
</tag1>
and file 2 has
<tag1 param='1'>
text2
</tag1>
you can do
<tag1 param='1'>
quoted
quoted
quoted
quoted
quoted
quoted
quoted
text
========
text2
<<<<<<<<
</tag1>
but if file2 has
<tag1 param='2'>
text
</tag1>
your conflict would need to be
quoted
quoted
quoted
quoted
quoted
quoted
quoted
<tag1 param='1'>
text
</tag1>
========
<tag1 param='1'>
text
</tag1>
<<<<<<<<
(although since < and > are special characters, they would really be >
and < in the file)
if there are nicer ways to do this, supporting them would be good, but as
long as the marker strings are configurable you can probably do so
you could change
the first string from >>>>>>> to <conflict option='1'>
the second string from ======== to </conflict><conflict option='2'>
the third string from <<<<<<< to </conflict>
and now instead of having to search for those special text strings, your
ODF editor would 'magicly' identify them and remind you that you hadn't
resolved all of them.
quoted
quoted
- knowing what data types we want to support _at the least_, and what
data types we keep for the free skate,
As of now, how about going for XML files. For this summer, we can go for
XML files and latex files can be handled later.
If your goal is just XML files (without any more specific goal, like ODF
or SVG), I am afraid that I think that project is not worth 4500 dollar
from Google's pocket. I mean, we are not talking peanuts here.
I see good support for XML being a superset of what's needed to support
ODF or SVG, not a subset.
or another way of putting it, the gitconfig definition for ODF would be a
shortcut for a longer XML definition with a long list of options.
to be accepted by google, they will need to feel that the work is worth
the money, so defining what file types you are going to support is an
important item. This can include saying 'by handling this type of tweak to
an XML file we can then handle file type Y instead of just file type X
with the same merge driver'
as you are considering this list, please think about the items I mentioned
earlier in the thread that would improve the support for config files and
maintainers files (unordered lines/paragraphs)
quoted
quoted
- a timeline (weekly milestones should be fine, I guess) what should
be achieved when, and
Timeline can be decided once we reach some conclusion and the work which
needs to be done become clear to us.
Last year, most successful applications detailed a proposed timeline in
their proposal...
Do not get me wrong, I want this project to succeed.
But on the other hand, I feel the obligation to be a bit demanding for the
gracious donation of Google: we _do_ want to have something stunningly
awesome at the end of the summer.
And that means that I have to get the impression from the student proposal
that something like that is at least _possible_.
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:46:25
Hi,
On Thu, 19 Mar 2009, david@lang.hm wrote:
I see good support for XML being a superset of what's needed to support
ODF or SVG, not a subset.
No, not at all. If we can get away with the default 3-way merge of Git,
the generic XML merge driver be damned.
I'd rather have more file types supported that are useful for the average
user, than a generic XML merge driver that is useful to only a handful of
people.
Ciao,
Dscho
I see good support for XML being a superset of what's needed to support
ODF or SVG, not a subset.
No, not at all. If we can get away with the default 3-way merge of Git,
the generic XML merge driver be damned.
I would agree, but unless you don't do any auto-merging and punt
everything to the 'conflict resolution tool' the existing merge drivers
won't work for a structured file. And if you do want to do that, it's not
a git project, it's a project for whatever tool you are working from to be
the GUI plus (possibly) a smidge of scripting to call that tool from git.
I'd rather have more file types supported that are useful for the average
user, than a generic XML merge driver that is useful to only a handful of
people.
we are both after the same thing, the most use to the average user.
you look at SVG, ODF word, ODF spreadsheet, OOXML, etc as completely
seperate things that should have support developed seperatly.
I look at the same formats and am seeing a strong similarity between them.
that being that they are all structured XML. so if you get the ability to
handle XML in a configurable way (and define the appropriate
configurations), you not only get the tools for these things, but many
others as well.
I would be a little disappointed if the result of the summer only handled
XML files (and more so if it only handled a handful of popular XML-based
files). I think that there are a number of file types that aren't handled
well by the current merge drivers. Saurabh has voiced the opinion that
many of these have similar problems as the XML situations, so it may end
up making sense to handle them in the same driver.
it would probably be a good thing to see suggestions from a bunch of
people as to what file types they see being useful.
David Lang
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:46:26
Hi,
On Thu, 19 Mar 2009, david@lang.hm wrote:
On Fri, 20 Mar 2009, Johannes Schindelin wrote:
quoted
I'd rather have more file types supported that are useful for the
average user, than a generic XML merge driver that is useful to only a
handful of people.
we are both after the same thing,
Apparently not...
the most use to the average user.
you look at SVG, ODF word, ODF spreadsheet, OOXML, etc as completely
seperate things that should have support developed seperatly.
No. I look at SVG, ODF text, ODF spreadsheet, etc as things with
completely different user interfaces.
And likewise, the merge _helper_, the very thing the user will get to see,
must have different user interfaces.
And I see much more potential for this project to fail in those different
user interfaces than something as _trivial_ (in relation) as XML merging.
Ciao,
Dscho
I'd rather have more file types supported that are useful for the
average user, than a generic XML merge driver that is useful to only a
handful of people.
we are both after the same thing,
Apparently not...
quoted
the most use to the average user.
you look at SVG, ODF word, ODF spreadsheet, OOXML, etc as completely
seperate things that should have support developed seperatly.
No. I look at SVG, ODF text, ODF spreadsheet, etc as things with
completely different user interfaces.
And likewise, the merge _helper_, the very thing the user will get to see,
must have different user interfaces.
I absolutly agree with this. the UI and merge _helper_ tools for these
different file formats are completely different.
And I see much more potential for this project to fail in those different
user interfaces than something as _trivial_ (in relation) as XML merging.
and the key thing that I am saying is that a properly done XML merge may
eliminate the need to do _any_ development of a merge helper tool.
so rather than focusing on what the merge helper tool is going to be and
what the UI for that is, I am focusing on the potential to eliminate any
need to hae a specific helper tool by making it so that the marked up
files can be manipulated with the existing tools for that file type.
David Lang
hi,
On Sat, Mar 21, 2009 at 2:20 AM, [off-list ref] wrote:
On Fri, 20 Mar 2009, Johannes Schindelin wrote:
quoted
On Thu, 19 Mar 2009, david@lang.hm wrote:
quoted
On Fri, 20 Mar 2009, Johannes Schindelin wrote:
quoted
I'd rather have more file types supported that are useful for the
average user, than a generic XML merge driver that is useful to only a
handful of people.
we are both after the same thing,
Apparently not...
quoted
the most use to the average user.
you look at SVG, ODF word, ODF spreadsheet, OOXML, etc as completely
seperate things that should have support developed seperatly.
No. I look at SVG, ODF text, ODF spreadsheet, etc as things with
completely different user interfaces.
And likewise, the merge _helper_, the very thing the user will get to see,
must have different user interfaces.
I absolutly agree with this. the UI and merge _helper_ tools for these
different file formats are completely different.
quoted
And I see much more potential for this project to fail in those different
user interfaces than something as _trivial_ (in relation) as XML merging.
and the key thing that I am saying is that a properly done XML merge may
eliminate the need to do _any_ development of a merge helper tool.
I also think that if xml file merging is done in a proper way and
according to the end-user editor, then it will not be needed to work
on the GUI part. For example, to merge the ODF files, we need to study
the merge conflict structure of Openoffice and will have to modify the
xml file in the same way so that OO can understand it. Similarly for
other file types.
so rather than focusing on what the merge helper tool is going to be and
what the UI for that is, I am focusing on the potential to eliminate any
need to hae a specific helper tool by making it so that the marked up files
can be manipulated with the existing tools for that file type.
David Lang
On Thu, Mar 19, 2009 at 6:19 AM, Johannes Schindelin
[off-list ref] wrote:
Sorry, by "data type" I tried to refer to the nature of the file. I
should have said "file type".
My concern is that xml will be focused on and html which is not xml
and yet similar and common will be left out.
--
Caleb Cushing
http://xenoterracide.blogspot.com