[prev in list] [next in list] [prev in thread] [next in thread]
List: fossil-users
Subject: Re: [fossil-users] Question about the file formats.
From: Scott Robison <scott () casaderobison ! com>
Date: 2016-12-21 16:12:18
Message-ID: CAPbjwUAL0tYR6r431a0Xb57RC3dxL5CPeWYjROtjm=-=Oa+-7Q () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Dec 20, 2016 10:59 PM, "John Found" <johnfound@asm32.info> wrote:
Well, the compression is the last thing I am talking about. It is
important, but not essential.
I am talking about several people working on one file and then fossil
merging the
changes automatically (of course if there is no conflicts in the edits).
I think the answer to your question is that merging depends on a knowledge
of the structure of data in order to detect where conflicts do or do not
exist. The structure of text files is "an ordered sequence of variable
length records" and the merge algorithm sees non overlapping changes as
independent. This is not always true, but it works often enough to be
useful. Because it is not always true, it is important to test post merge &
pre commit.
The merge algorithm could be modified to work with other data structures
but it would still require the property that non overlapping changes be
independent (have no impact on previous or future data). With a "binary"
format there are many other things that could go wrong. Fixed length
records, specific requirements for alignment, embedded non symbolic
references to other parts of the file are the first few that come to mind.
Without specific knowledge of the structure of the data, merge can't work.
Even with knowledge of the structure of text files, it can still get things
wrong.
[Attachment #5 (text/html)]
<div dir="auto"><div><div class="gmail_extra"><div class="gmail_quote">On Dec 20, \
2016 10:59 PM, "John Found" <<a \
href="mailto:johnfound@asm32.info">johnfound@asm32.info</a>> wrote:<br \
type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex">Well, the compression is the last thing I am talking \
about. It is important, but not essential.<br> <br>
I am talking about several people working on one file and then fossil merging the<br>
changes automatically (of course if there is no conflicts in the \
edits).</blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">I \
think the answer to your question is that merging depends on a knowledge of the \
structure of data in order to detect where conflicts do or do not exist. The \
structure of text files is "an ordered sequence of variable length records" \
and the merge algorithm sees non overlapping changes as independent. This is not \
always true, but it works often enough to be useful. Because it is not always true, \
it is important to test post merge & pre commit.</div><div \
dir="auto"><br></div><div dir="auto">The merge algorithm could be modified to work \
with other data structures but it would still require the property that non \
overlapping changes be independent (have no impact on previous or future data). With \
a "binary" format there are many other things that could go wrong. Fixed \
length records, specific requirements for alignment, embedded non symbolic references \
to other parts of the file are the first few that come to mind.</div><div \
dir="auto"><br></div><div dir="auto">Without specific knowledge of the structure of \
the data, merge can't work. Even with knowledge of the structure of text files, \
it can still get things wrong.</div><div dir="auto"></div></div>
[Attachment #6 (text/plain)]
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic