Browse Source

Add prototype docs and tests

Andrew Young 8 years ago
parent
commit
91b758c5eb
29 changed files with 875 additions and 0 deletions
  1. 0 0
      AUTHORS
  2. 0 0
      COPYING
  3. 0 0
      ChangeLog
  4. 0 0
      INSTALL
  5. 0 0
      Makefile.am
  6. 0 0
      NEWS
  7. 0 0
      README
  8. 232 0
      config/ylwrap
  9. 0 0
      configure.ac
  10. 291 0
      doc/implementation.org
  11. 143 0
      doc/todo.org
  12. 9 0
      tests/t1-0.org
  13. 10 0
      tests/t1-1.org
  14. 13 0
      tests/t1-2.org
  15. 7 0
      tests/test.sh
  16. 15 0
      tests/test1.org
  17. 20 0
      tests/test1/t1-0.org
  18. 19 0
      tests/test1/t1-1.org
  19. 19 0
      tests/test1/t1-2.org
  20. 5 0
      tests/test2.org
  21. 2 0
      tests/test2/t1-0.org
  22. 7 0
      tests/test2/t1-1.org
  23. 6 0
      tests/test2/t1-2.org
  24. 27 0
      tests/test3.org
  25. 9 0
      tests/test3/t1-0.org
  26. 10 0
      tests/test3/t1-1.org
  27. 10 0
      tests/test3/t1-2.org
  28. 3 0
      tests/test4.org
  29. 18 0
      tests/tout.org

+ 0 - 0
AUTHORS


+ 0 - 0
COPYING


+ 0 - 0
ChangeLog


+ 0 - 0
INSTALL


+ 0 - 0
Makefile.am


+ 0 - 0
NEWS


+ 0 - 0
README


+ 232 - 0
config/ylwrap

@@ -0,0 +1,232 @@
+#! /bin/sh
+# ylwrap - wrapper for lex/yacc invocations.
+
+scriptversion=2011-08-25.18; # UTC
+
+# Copyright (C) 1996-2012 Free Software Foundation, Inc.
+#
+# Written by Tom Tromey <tromey@cygnus.com>.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+# As a special exception to the GNU General Public License, if you
+# distribute this file as part of a program that contains a
+# configuration script generated by Autoconf, you may include it under
+# the same distribution terms that you use for the rest of that program.
+
+# This file is maintained in Automake, please report
+# bugs to <bug-automake@gnu.org> or send patches to
+# <automake-patches@gnu.org>.
+
+case "$1" in
+  '')
+    echo "$0: No files given.  Try '$0 --help' for more information." 1>&2
+    exit 1
+    ;;
+  --basedir)
+    basedir=$2
+    shift 2
+    ;;
+  -h|--h*)
+    cat <<\EOF
+Usage: ylwrap [--help|--version] INPUT [OUTPUT DESIRED]... -- PROGRAM [ARGS]...
+
+Wrapper for lex/yacc invocations, renaming files as desired.
+
+  INPUT is the input file
+  OUTPUT is one file PROG generates
+  DESIRED is the file we actually want instead of OUTPUT
+  PROGRAM is program to run
+  ARGS are passed to PROG
+
+Any number of OUTPUT,DESIRED pairs may be used.
+
+Report bugs to <bug-automake@gnu.org>.
+EOF
+    exit $?
+    ;;
+  -v|--v*)
+    echo "ylwrap $scriptversion"
+    exit $?
+    ;;
+esac
+
+get_dirname ()
+{
+  case $1 in
+    */*|*\\*) printf '%s\n' "$1" | sed -e 's,\([\\/]\)[^\\/]*$,\1,';;
+    # Otherwise,  we want the empty string (not ".").
+  esac
+}
+
+quote_for_sed ()
+{
+  # FIXME: really we should care about more than '.' and '\'.
+  sed -e 's,[\\.],\\&,g'
+}
+
+# The input.
+input="$1"
+shift
+# We'll later need for a correct munging of "#line" directives.
+input_sub_rx=`get_dirname "$input" | quote_for_sed`
+case "$input" in
+  [\\/]* | ?:[\\/]*)
+    # Absolute path; do nothing.
+    ;;
+  *)
+    # Relative path.  Make it absolute.
+    input="`pwd`/$input"
+    ;;
+esac
+
+pairlist=
+while test "$#" -ne 0; do
+  if test "$1" = "--"; then
+    shift
+    break
+  fi
+  pairlist="$pairlist $1"
+  shift
+done
+
+# The program to run.
+prog="$1"
+shift
+# Make any relative path in $prog absolute.
+case "$prog" in
+  [\\/]* | ?:[\\/]*) ;;
+  *[\\/]*) prog="`pwd`/$prog" ;;
+esac
+
+# FIXME: add hostname here for parallel makes that run commands on
+# other machines.  But that might take us over the 14-char limit.
+dirname=ylwrap$$
+do_exit="cd '`pwd`' && rm -rf $dirname > /dev/null 2>&1;"' (exit $ret); exit $ret'
+trap "ret=129; $do_exit" 1
+trap "ret=130; $do_exit" 2
+trap "ret=141; $do_exit" 13
+trap "ret=143; $do_exit" 15
+mkdir $dirname || exit 1
+
+cd $dirname
+
+case $# in
+  0) "$prog" "$input" ;;
+  *) "$prog" "$@" "$input" ;;
+esac
+ret=$?
+
+if test $ret -eq 0; then
+  set X $pairlist
+  shift
+  first=yes
+  # Since DOS filename conventions don't allow two dots,
+  # the DOS version of Bison writes out y_tab.c instead of y.tab.c
+  # and y_tab.h instead of y.tab.h. Test to see if this is the case.
+  y_tab_nodot="no"
+  if test -f y_tab.c || test -f y_tab.h; then
+    y_tab_nodot="yes"
+  fi
+
+  input_rx=`get_dirname "$input" | quote_for_sed`
+
+  while test "$#" -ne 0; do
+    from="$1"
+    # Handle y_tab.c and y_tab.h output by DOS
+    if test $y_tab_nodot = "yes"; then
+      if test $from = "y.tab.c"; then
+        from="y_tab.c"
+      else
+        if test $from = "y.tab.h"; then
+          from="y_tab.h"
+        fi
+      fi
+    fi
+    if test -f "$from"; then
+      # If $2 is an absolute path name, then just use that,
+      # otherwise prepend '../'.
+      case "$2" in
+        [\\/]* | ?:[\\/]*) target="$2";;
+        *) target="../$2";;
+      esac
+
+      # We do not want to overwrite a header file if it hasn't
+      # changed.  This avoid useless recompilations.  However the
+      # parser itself (the first file) should always be updated,
+      # because it is the destination of the .y.c rule in the
+      # Makefile.  Divert the output of all other files to a temporary
+      # file so we can compare them to existing versions.
+      if test $first = no; then
+        realtarget="$target"
+        target="tmp-`echo $target | sed s/.*[\\/]//g`"
+      fi
+      # Munge "#line" or "#" directives.
+      # We don't want the resulting debug information to point at
+      # an absolute srcdir.
+      # We want to use the real output file name, not yy.lex.c for
+      # instance.
+      # We want the include guards to be adjusted too.
+      FROM=`echo "$from" | sed \
+            -e 'y/abcdefghijklmnopqrstuvwxyz/ABCDEFGHIJKLMNOPQRSTUVWXYZ/'\
+            -e 's/[^ABCDEFGHIJKLMNOPQRSTUVWXYZ]/_/g'`
+      TARGET=`echo "$2" | sed \
+            -e 'y/abcdefghijklmnopqrstuvwxyz/ABCDEFGHIJKLMNOPQRSTUVWXYZ/'\
+            -e 's/[^ABCDEFGHIJKLMNOPQRSTUVWXYZ]/_/g'`
+
+      sed -e "/^#/!b" -e "s,$input_rx,$input_sub_rx," -e "s,$from,$2," \
+          -e "s,$FROM,$TARGET," "$from" >"$target" || ret=$?
+
+      # Check whether header files must be updated.
+      if test $first = no; then
+        if test -f "$realtarget" && cmp -s "$realtarget" "$target"; then
+          echo "$2" is unchanged
+          rm -f "$target"
+        else
+          echo updating "$2"
+          mv -f "$target" "$realtarget"
+        fi
+      fi
+    else
+      # A missing file is only an error for the first file.  This
+      # is a blatant hack to let us support using "yacc -d".  If -d
+      # is not specified, we don't want an error when the header
+      # file is "missing".
+      if test $first = yes; then
+        ret=1
+      fi
+    fi
+    shift
+    shift
+    first=no
+  done
+else
+  ret=$?
+fi
+
+# Remove the directory.
+cd ..
+rm -rf $dirname
+
+exit $ret
+
+# Local Variables:
+# mode: shell-script
+# sh-indentation: 2
+# eval: (add-hook 'write-file-hooks 'time-stamp)
+# time-stamp-start: "scriptversion="
+# time-stamp-format: "%:y-%02m-%02d.%02H"
+# time-stamp-time-zone: "UTC"
+# time-stamp-end: "; # UTC"
+# End:

+ 0 - 0
configure.ac


+ 291 - 0
doc/implementation.org

@@ -0,0 +1,291 @@
+#+TITLE: Org Merge Driver Implementation Notes
+* Project
+** Contact Information
+- Andrew Young, youngar17 at gmail.com
+** Milestones
+- Start Project
+- prototype parser (limited functionality)
+- prototype tree construction
+- prototype tree change detection
+- prototype tree merging
+- finish prototype
+- tree data interface
+- org-mode parser
+- general merging rule interface
+- org mode change detection
+- org mode merging rules
+- additional features
+- finishing touches
+- documentation and distribution
+** coding conventions
+- [[http://www.gnu.org/software/emacs/elisp/html_node/Coding-Conventions.html][elisp conventions]]
+- must sign a [[http://orgmode.org/worg/org-contribute.html][copyright grant]] for the FSF!
+- [[http://www.gnu.org/prep/standards/standards.html][GNU Coding Standards]]
+- use [[www.doxygen.org/][Doxygen]] to document the code
+* Notes
+* General Merging Implementation
+** Elements
+- an element is any individual element in a file
+- elements are stored as a hierarchy
+  - this is to identify not just changes of line-by-line content, but also of
+    relationships (e.g. data is moved)
+- elements are defined by their mapping entity
+- elements may not always have a perfectly identifying trait
+  - i.e. a unique object identifier
+- defined by:
+  - how to read elements
+  - how to write the elements
+  - what changes are available
+  - how to map them
+  - how to merge changes
+- every element has a parent, and a list of sub-elements
+  - the sub elements list can be empty
+- an ordered set of elements are represented by:
+  - mapping which needs identical parents
+  - each element is the next one's parent
+** Node Identification
+- Node identification is mapping elements from one file to the same
+node in a different file
+- whether or not two elements are mapped depends on the element type,
+  and it's mapping rules
+- a mapping which is missing another element should represent an
+  element being added or removed
+  - this is really up to the element's rules, it can do whatever it
+    wants with the information
+- two main types of mappings:
+  - one which needs to have the same mapped parent
+  - one which does not need to have the same parent
+- a single mapping is from 1 file to another, but can have more then
+  one elements from each
+  - this can be the case for indistinguishable elements
+- mapping function an element type should have access to:
+  - know if the element's parents are mapped
+  - the element data for each
+  - if the compared element is already mapped, it should have access
+    to the mapping
+- mapping function will not have access to:
+  - the coordinate of the element in the document
+- mapping may be affected by whether the elements are considered
+  'ordered' or 'unordered'
+  - ordered mapping can use an edit script and detect differences in a
+    sequence with exact matching rules
+  - unordered mapping will not take into account the order in which
+    items appear in
+- mapping function can consider more elements of a
+- elements which are indistinguishable
+** Actions or Changes
+- Different changes to the same node can be grouped into 3 categories:
+  - identical changes
+  - non-conflicting changes
+  - conflicting changes
+- changes will only be classified after all changes have been detected
+- a change will be applied to a mapping
+- These changes apply to all elements:
+  - adding element
+  - removing element
+  - reordering children
+- Every other element will have their own set of changes
+  - ie: property changing, moving
+  - these will be detected by the program upon successful mapping between files
+  - at the same time as all other changes
+- if text has not changed in a branch of elements, then it will not be mapped?
+  - this will not work, if mapping can happen across different levels
+
+** rules
+- should merging rules should consider all changes across all elements
+  - or only changes to a specific element
+** Results
+- results will be printed in standard conflicting file style:
+#begin_quote
+>>>
+there file
+===
+your file
+<<<
+#end_quote
+- the contents of a conlflicting change will have to be printed by each change pair representing a conflict
+** Implementation Notes
+- Very large file support -> stream reading files
+  - this could cause many slow-downs
+- #begin_ blocks could cause a problem
+- Tables
+- Agendas? Calendar?
+- meta data
+  - stored with the element?
+  - could be used to assist mapping (i.e. UIDs)
+- need to support writing certain text in different encoding
+- need to be able to add and remove features / rule conservatism
+  - mapping conservatism
+  - this will automatically affect change detection
+    - will rules be needed for this?
+  - change merging rules
+- there will be some user defined values that are not defined in this file
+- are there any other org-mode rules that wont be in the file?
+
+** What I don't have to do
+- detection of file name changes
+** Potential Problems
+*** Commit and Merge timing problems
+A merge will always be the same for two files.  However, the order of
+mergin and branching can sometimes produce different files.  This
+problem stems from the fact that 'diff' is the difference between two
+repository states, and merges aren't transitive across a branches
+history. http://r6.ca/blog/20110416T204742Z.html
+
+example master and branch
+
+edit branch
+edit master
+merge master -> branch
+edit master
+merge master -> branch
+
+can produce different results from a merge than
+
+edit branch
+edit master
+edit master
+merge master -> branch
+
+how to combat?
+I think that this can be combated by keeping unique IDs for headings, like in mobile org.
+
+caveats?
+what if someone is relying on the non-transitive behavior? (i don't know how)
+
+* Prototype
+** Parsing
+- elements: the only element in the prototype is headlines
+- headlines
+  - identified by a newline staring with stars and ending with a space
+  - headline level is the number of stars
+  - following text is the title
+- everything not in a title is in the text
+  - text in the prototype is not its own element, just a property of
+    the heading
+- the file is parsed into a tree
+  - with all headings considered a subheading, top level headings are
+    a subheading of the document
+- if a heading level is skipped (i.e. going from * to ***) it is still
+  a child of the other
+- headings are all assumed to be unordered
+- the entire file is loaded into memory and must remain until an
+  org_document no longer needs to exist
+** Mapping
+- mapping is the process of matching two headings in a file
+- a mapping can represent indistinguishable elements
+- it is expected that as the files are processed, they will change into
+- mappings are stored in a hiearchy, with the same as the elements
+- mapping happens with a locality heurisitic
+** Changes
+- detected by matching a heading title exactly
+- measuring changes from the ancestor to each of the new files
+- each heading will have 2 pointers to changes that affect them
+- if there are 2 changes to a heading, then there is a conflict
+- if there are two headings of the same name, it will always produce a
+  conflict (should this be implemented?) when removing, or when 2 change text
+- every heading which is indistinguishable must have headings
+- changes are 'add heading', 'remove heading', 'change text'
+- a heading must be in the same place
+- changes are actually applied when the document is printed to a file
+  - conflict messages are automatically inserted
+*** Changes
+- There are only basic changes for unordered lists implemented:
+- Add heading
+  - when a new heading has been added to the current spot
+- Remove heading
+- Modify text
+- Move a heading
+** Difference Detection
+- use the same difference detection algorithm used in the UNIX diff
+  program[fn:4] for ordered lists
+*** Output
+-
+* Org-merge-tool
+** Org-Mode Data Representation
+- Headings will be considered unordered trees
+  - A heading will be matched by its UID if it has one
+  - headings will be matched by their title otherwise
+- Elements below a heading will be considered unordered
+- Numbered lists
+  - Identified as a whole if it matches exactly
+  - 
+*** All Org-mode Elements
+- headlines
+  - never ordered
+  - keywords not apart of the name
+- keywords
+  - TODO, user defined, properties
+  - perfile keywords #+TODO:
+- cookies: [#A]
+  - always in square brackets?
+  - [#A], [0%], [0/0]
+- Tags :tag:
+  - only for headlines
+  - #+filetags for tags for everytihng in the file
+- plain lists
+  - within an outline tree entry
+  - unordered (start with '-', '+', '*' as bullets)
+  - ordered (numeral followed by 
+  - description (i.e. ::) (considered unordered items)
+  - ends at two blank lines or less indented
+  - must have the same indentation level
+  - can have checkboxes
+- blocks #BEGIN_.. blocks
+  - #+STARTUP
+- Drawers
+  - :DRAWERNAME:  this dra :END:
+  - time stamp note in a drawer (C-c C-z)
+  - drawers need to be defined in variable org-drawers
+    - or by file basis: #+DRAWERS: HIDDEN PROPERTIES STATE
+  - PROPERTIES for properties
+- Properties
+  - always in PROPERTIES drawer
+- Timestamps (in < > or [ ] brackets at the end of a headline)
+- Footnotes[[fn:2]
+  - [fn:1] footntoes!
+  - footnote inline definitions[fn:3]
+    - [fn:: this is inline]
+  - there is a function to automatically
+  - footnote defintions do not need to be ordered
+  - see org-footnote-auto-label
+- Tables (needs more work)
+  - calculations? exist?
+  - table row order might matter
+  - '/' must be first field,
+    - only 1?
+  - Table references will be updated to match
+- hooks?
+  - org-footnote-auto-adjust fixes footnote defintion order
+** Parser
+- possibly a more robust parser could be written by a generator
+- currently exists no Org-mode parser
+- could write the ground-work for a bison parser
+- need to use macros to automatically generate function hooks for
+  elements
+- the parser will be used in conjuction with the generalized tree
+  merging algorithm
+** Modification Guesser?
+1. look for differences in the files
+   1. this seems like it might have to be O(n^2)
+2. create a list of changes (ordered?)
+   1. tree of changes (first element is nothing)
+   2. find conflicting changes
+3. process the conflicting changes, applying generic rules
+
+** Modification Merger
+- if A and B both add a heading with the same name in the same place,
+  should it conflict or should both be added?
+- if a heading is moved in A, and B adds a subheading, should this
+  conflict as B is editing a removed heading in A, or should it merge
+  with the new subheading under the moved heading in A
+
+* Footnotes and Bibiliography
+-  [[http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c][git-merge-changelog]]provides a good example on how to write a merge driver
+- [[http://www.hiit.fi/files/fi/fc/papers/doceng04-pc.pdf][Three-way XML Merge]]
+[fn:4] The basic algorithm is described in "An O(ND) Difference
+Algorithm and its Variations", Eugene W. Myers, 'Algorithmica' Vol. 1
+No. 2, 1986, pp. 251-266; and in "A File Comparison Program", Webb
+Miller and Eugene W. Myers, 'Software--Practice and Experience'
+Vol. 15 No. 11, 1985, pp. 1025-1040. The algorithm was independently
+discovered as described in "Algorithms for Approximate String

+ 143 - 0
doc/todo.org

@@ -0,0 +1,143 @@
+#+TITLE: Org Merge Driver To-do List
+#+STARTUP: overview
+#+AUTHOR: Andrew Young
+#+DESCRIPTION: TODO list for org merge driver
+
+* Things To Do
+** Webpage
+*** DONE Add the original posting to the proposal page
+    - State "DONE"       from "NEXT"       [2012-05-09 Wed 01:36]
+*** TODO Fix all references to the project to be the same name on the webpage
+*** TODO Fix the reference to the git repository after it has been created
+*** TODO Update the usage instructions
+*** TODO Add implementation notes
+- even though nothing is decided, there must be something I can add
+** Prototype
+*** DONE fix up documentation
+    - State "DONE"       from "TODO"    [2012-05-09 Wed 01:34]
+*** DONE Write real manual
+    - State "DONE"       from "NEXT"       [2012-05-09 Wed 01:34]
+- manual, how to use it
+- now in the root README
+*** DONE Finish the parser
+    - State "DONE"       from "NEXT"       [2012-05-10 Thu 19:03]
+- make sure the new headings are being put in the right spot
+  - means: compare level of new heading with old heading to add it in
+    the right spot
+  - possibly add the new heading to the propper spot right as the next
+    one is started
+*** DONE Implement a heading tree printer
+    - State "DONE"       from "NEXT"       [2012-05-09 Wed 23:24]
+- really a org_document_to_file function
+*** TODO Add a TAP for the program which demonstrates its use
+- test anything protocol
+*** DONE Write an introductory warning
+    - State "DONE"       from "NEXT"       [2012-05-10 Thu 19:03]
+- this program assumes things about the structure and use of org-mode
+  and org files. If the way you use org files does not match this,
+  then it may corrupt your data! Please be very aware of what
+  assumptions this program makes before using. I (nor anyone other
+  than yourself) can be held accountable for the results of using this
+  program.
+*** DONE Use Gnulib diffseq to merge
+    - State "DONE"       from "NEXT"       [2012-05-16 Wed 22:26]
+*** TODO Fix memory usage
+- nothing is being unmalloced
+- write destroy functions
+  - one for document, heading, look at ?gl_list_free? for list notes
+*** DONE Start working on the change detection
+    - State "DONE"       from "NEXT"       [2012-05-16 Wed 22:25]
+*** TODO Create a heading mapping
+*** TODO Begin work on the change merging
+*** TODO Finish the prototype
+** Program
+*** Update autotool files
+*** Find a unit test
+- currently looking at "check" (based off of auto-something)
+  - it is not based off of 
+*** Find a parser/lexer
+* Log
+** [2012-05-07 Mon]
+- modify gl_list.h to not inline functions
+- write parser, reads the files but does not create a proper list
+** [2012-05-08 Tues]
+*** split source files
+- the files should really be split up by their use
+*** split commits
+- branch for the prototype
+- add documentation
+- add gnu_lib list
+- add read file
+- add main program
+  - with only org_ structs
+- add parser
+*** finally started uploading code
+** [2012-05-09 Wed]
+- tried to add some testing code
+  - went with TAP at first, but decided it wasn't what I wanted
+  - went with heavier duty unit testing (called 'check'), but it was
+    *too* heavy duty
+  - trying to go back to TAP
+- tried to compile the parser into a library instead of statically
+  linking into the program
+  - got it working but reverted; this is more useful for the final
+    project (and with the unit testing removed there was no point)
+- wrote a manual for using the program (for when it is eventually done)
+- tried to make all the random bits of (evidently pointless) work presentable
+** [2012-05-10 Thu]
+- looked into anonymous functions in C, definitely not portable
+- wrote a function to recursively call other functions on a tree
+- wrote a function to print a org_doc back into a file
+- finally finished the parser, i probably made it more correct than
+  necessary to show how it would work
+- fixed a lot of the documentation in the code I have written, adding
+  GPL warnings at the top of all my source files
+- finally fixed the problem with gl_list not compiling inline
+  functions. I needed to include autoconf's config.h before it to
+  define the _HAVE_INLINE_ macro.
+- starting to think about the best way to finish off the prototype
+  - this involves the 'tricky' part of the program: finding changes
+    and merging them.
+- looking into different parser generators for the final program.  I
+  am worried about both speed and robustness when it comes to creating
+  a parser
+** [2012-05-11]
+- looking into more robust parser generators, specifically ones that
+  will be extensible, easy to use, and most importantly fast
+- typically Bison and yacc look very good
+** [2012-05-12]
+- reading about compilers, trying to see if the traditional structure
+  will lead to hints as to how to set up my code
+- reading a book known as 'the dragon book'
+- found out that you can collapse a heading which is inside
+  a #+begin_src: block
+  - is this a bug?
+** [2012-05-13]
+- spending some time going through the manual again to figure out what
+** [2012-05-14]
+- thinking about the best way to set up a difference detector.
+- I am finding that a lot of ideas I have about what rules to use to
+  merge might not be desirable for people
+- how can I set it up, so that the rules can be customized?
+** [2012-05-15]
+- After reading papers about 'sequence difference seeking algorithms',
+  I decided that it would be too much work to implement on from
+  scratch for the prototype
+- Found an implementation in Gnulib (should have checked there sooner!)
+- spending my day attempting to include it into the project
+** [2012-05-16 Wed]
+- deciding that for the prototype, I will only do change detection on
+  a heading level
+  - this makes for kind of a bad prototype
+  - I will have to really make sure I consider how having a larger
+    amount of elements will affect the project
+- it is really confusing trying to match headings when one is not unique
+- it will be necessary to create a mapping of headings in from one
+  file to another, where the mapping says which headings are the same,
+  which are non-unique non-distinguishable, and which have no matches
+** [2012-05-19 Sat]
+- starting the change detection
+- must finish the fucntion to create an empty tree of mappings from
+  the origin file
+  - this will involve copying the code from thre recursive function
+    and manipulating it to create the treec

+ 9 - 0
tests/t1-0.org

@@ -0,0 +1,9 @@
+* heading 1
+** test heading
+:PROPERTIES:
+:ID: 100
+:END:
+- this is just a test
+* heading 2
+** test heading
+- this is a different heading

+ 10 - 0
tests/t1-1.org

@@ -0,0 +1,10 @@
+* heading 1
+** test heading
+- this is a different heading
+* heading 3
+** heading 4
+*** test heading
+:PROPERTIES:
+:ID: 100
+:END:
+- this is just a test

+ 13 - 0
tests/t1-2.org

@@ -0,0 +1,13 @@
+* heading 1
+** test heading
+:PROPERTIES:
+:ID: 100
+:END:
+- updated line in file 2
+* heading 2
+- new text under heading 2
+- this will conflict since heading 2
+  deleted in file 1
+** test heading
+- this is a different heading
+- this line added in file 2

+ 7 - 0
tests/test.sh

@@ -0,0 +1,7 @@
+#! /bin/sh
+
+# print a git diff of the files
+git merge-file -p t1-1.org t1-0.org t1-2.org
+# run the program with some test files
+../src/org-merge-driver t1-1.org t1-2.org t1-0.org tout.org
+cat tout.org

+ 15 - 0
tests/test1.org

@@ -0,0 +1,15 @@
+- this is going to be a test
+* Heading 1
+- this is such a test
+* Heading 2
+- we are testing this
+*** Heading 3
+- I'm wondering what this will do
+
+* Heading 4
+- testing this is so much fun 
+** Heading 5
+*** Heading 6
+*** Heading 7
+** Heading 8
+- some text

+ 20 - 0
tests/test1/t1-0.org

@@ -0,0 +1,20 @@
+* deleted in both files
+- this text will be deleted too
+* unchanged 1
+:PROPERTIES:
+:ID: 100
+:END:
+- this is just a test
+* unchanged 1
+* deleted in first
+- we are testing this
+** deleted in second
+- I'm wondering what this will do
+* unchanged 2
+- testing this is so much fun 
+** unchanged 3
+*** moved level 2 in first
+- some text
+*** moved level 2 in second
+** different text in both
+- different text in both

+ 19 - 0
tests/test1/t1-1.org

@@ -0,0 +1,19 @@
+- this text is new, but the same in both files
+* unchanged 1
+:PROPERTIES:
+:ID: 100
+:END:
+- this is just a test
+* unchanged 1
+** deleted in second
+- I'm wondering what this will do
+* new in file 1
+* unchanged 2
+- testing is so much fun
+** sub new heading in file 1
+** unchanged 3
+** moved level 2 in first
+*** moved level 2 in second
+** different text in both
+- file 1 different text
+

+ 19 - 0
tests/test1/t1-2.org

@@ -0,0 +1,19 @@
+- this text is new, but the same in both files
+* unchanged 1
+:PROPERTIES:
+:ID: 100
+:END:
+- this is just a test
+* unchanged 1
+* deleted in first
+- we are testing this
+* unchanged 2
+- testing is so much fun
+** unchanged 3
+*** file 2 new sub-heading
+**** file 2 new sub-sub-heading
+*** moved level 2 in first
+** moved level 2 in second
+** different text in both
+- different text from file 2
+

+ 5 - 0
tests/test2.org

@@ -0,0 +1,5 @@
+* h
+t
+** hh
+ *
+* h

+ 2 - 0
tests/test2/t1-0.org

@@ -0,0 +1,2 @@
+* original heading
+- here is some text

+ 7 - 0
tests/test2/t1-1.org

@@ -0,0 +1,7 @@
+- conflicting text in file 1
+* original heading
+- here is some text
+- add some text in file 1
+** New heading in file 1
+- more text
+*** Sub new heading in file 1

+ 6 - 0
tests/test2/t1-2.org

@@ -0,0 +1,6 @@
+#+TITLE: A New Title In File 2
+* original heading
+- here is some text
+** File 2 new sub heading
+* A new heading in file 2
+- with some text

+ 27 - 0
tests/test3.org

@@ -0,0 +1,27 @@
+ **
+  ****
+** ***
+* * * *
+  **
+
+  **
+**** ***
+ *
+*** *
+** **
+* ***
+
+*aa
+ *ab
+*-*
+****ac
+
+** 
+*****
+
+#+begin_src C
+/*
+* this is source code */
+
+return 1+2;
+#+end_src:

+ 9 - 0
tests/test3/t1-0.org

@@ -0,0 +1,9 @@
+* heading 1
+** test heading
+:PROPERTIES:
+:ID: 100
+:END:
+- this is just a test
+* heading 2
+** test heading
+- this is a different heading

+ 10 - 0
tests/test3/t1-1.org

@@ -0,0 +1,10 @@
+* heading 1
+** test heading
+- this is a different heading
+* heading 3
+** heading 4
+** test heading
+:PROPERTIES:
+:ID: 100
+:END:
+- this is just a test

+ 10 - 0
tests/test3/t1-2.org

@@ -0,0 +1,10 @@
+* heading 1
+** test heading
+:PROPERTIES:
+:ID: 100
+:END:
+- updated line in file 2
+* heading 2
+** test heading
+- this is a different heading
+- this line added in file 2

+ 3 - 0
tests/test4.org

@@ -0,0 +1,3 @@
+* this is yet another test
+- with windows style endlines
+- i hope this works

+ 18 - 0
tests/tout.org

@@ -0,0 +1,18 @@
+<<<<<<< yours: t1-1.org
+=======
+* heading 2
+- new text under heading 2
+- this will conflict since heading 2
+  deleted in file 1
+>>>>>>> theirs: t1-2.org
+* heading 3
+** heading 4
+** test heading
+:PROPERTIES:
+:ID: 100
+:END:
+- updated line in file 2
+* heading 1
+** test heading
+- this is a different heading
+- this line added in file 2