Re: [fossil-users] Question about the file formats.

[Scott Robison]

On Dec 20, 2016 10:59 PM, "John Found"  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.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Question about the file formats.

[Joerg Sonnenberger]

On Tue, Dec 20, 2016 at 08:48:27PM +0200, John Found wrote:
> What makes the binary files different from the text files? The presence or 
> absence of
> 0 bytes does not seems to make serious difference for processing by the same 
> algorithms.

Many text formats allow merging changes from one version to another with
minimal context. E.g. let's say you start from a C file and modify a line
in the middle in your checkout and then update your tree. Someone else
added a new function at the beginning of the file. This creates a
conflict and Fossil will try to resolve it by finding the context of the
line you modified in a similiar place and then readd that change. While
this doesn't work all the time for text files, it has a high chance of
working. Even if it doesn't work i.e. because the changes overlap, it
provides enough information that a user can typically do the same.

The same kind of tooling could be provided for binary formats, but it is
rarely exist directly.

Joerg
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Question about the file formats.

[Stephan Beal]

On Dec 21, 2016 10:57 AM, "Warren Young"  wrote:


That is exactly what I’m talking about in my BMP vs PNG examples.

If you wish to discuss a different file type than than bitmap graphics,
give your own example.  Until then, mine is the only concrete example we
have available to discuss.


Zip files and similar archives apply here as well, i think (that includes
modern office suite formats,  many of which are zip files).  Without
knowing how to dissect them and diff the individual components, it can only
perform generic binary delta compression. i opine, without any proof to
back it up, that the compression  results would not be appreciably better
were fossil to "know" about such content (for most common file formats),
while performance, complexity, and memory costs would be negatively
impacted.

- stephan
Sent from a mobile device, possibly from bed. Please excuse brevity, typos,
and top-posting.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users