1st-class subfile renaming

12.4: news.adde/fs/1st-class subfile renaming:

. Brandon Casey June 20th, 2007,
mentioned the idea of 1st-class subfile renamingwhich is a version tracking system that recognizes
when file modifications consist of subfile moves:
"( I split the file into two files in my repo.
File is modified in source repo.
I retrieve changes from source repo.
Will changes be correctly applied to
relevant sections in the two new files?
).
. Casey was responding to an article about
www.markshuttleworth.com/archives/123
tracking renames as a first class operation,
which I would call 1st-class file renaming;
so, Casey's idea is 1st-class subfile renaming .
. the minimalist style of version tracking
is to wait for a commit,
and then respond to modifications:
# directory changes are seen as
file {adds, deletes};
# file modifications are recorded with a
line-oriented diff' file .
. in previous notes on subfiles,
the system recognizes structure within files:
eg, html files have header tags, H1, H2, ... H6;
and, each represents a hierarchical subfile,
as do paragraphs, divisions, and other enclosing tags .
. the file system is just a tree of pointers;
likewise, this tree extends to subfiles;
and files become pointers to sections of text
which are actually in a database
named by their creation date & author
(plus an optional serial# for when
several subfiles have the same create date;
for example when a file is modified by
having some paragraphs inserted,
the paragraphs' create dates are considered to be
at the file's modified time .
).
. the branch copies db names
and each simultanious branch belings to one author;
so, that author'name must be part of a subfile's db name .

1st-class subfile renaming:

. the folder-subfile system is a tree:
a collection of nodes
(visualized as forks for representing enclosures )
and edges
(visualized as branches for representing
the things they contained by an enclosure ).
. a folder-representing node is thus remembering
# the name of the folder,
# edges to all nodes the folder contains;
likewise, a file-representing node has the file's name,
and the edges to subfiles it contains;
but, a paragraph-representing node
has a position number in place of a name
( so, when a paragraph gets inserted,
that bumps all the position numbers of paragraphs below
(within that subfile not the entire file)).

. when version-tracking for subfiles,
the nodes that were revised
are replaced with version-representing nodes
(version node) with edges to
both the replaced node,
and to the new node created by the revision;
in summary,
modified nodes are presented as a menu
of version choices;
eg, a folder-move creates version nodes twice:
once at both the source and destination nodes .
12.5:
. what if the version node is not the smartest
way to see changes?
the friendliest way is to show the various views:
# toc's for each version:
when there a high use of 2 views,
make sure both are fully built (not defined as a script)
the db will then be like a book with 2 toc's (table of contents).
# index:
. search of index finds every instance
showing you the pathnames,
and grouping together occurrences of
1 object is in several locations across versions .
# glossary:
. the place for histories of how a name has been used,
and why it has been changed from and to other names .
. this would include the human view of
why there systematic renames in certain versions .