On Thu, Oct 16, 2014 at 8:59 PM, Ron W <ronw.m...@gmail.com> wrote:
>
> After doing some research,
>
More research...
In the SVN dump file, deltas are optional, so an initial implementation can
omit dealing with deltas.
SVN dump files do not have manifests. There is a revision artifact followed
by file artifacts, so the manifest would be created file-by-file. Does
libfossil need a complete manifest before it can accept file data?
How does libfossil expect the file content? SVN::Dump::Reader gives me a
byte string that I could then either give to libfossil or write to a temp
file.
A caveat: SVN also has directory artifacts. As best I can tell, a
"directory add" operation can safely be ignored (except the user might be
expecting an empty directory to be created, so might need to "add" a
placeholder file).
A "directory delete" operation, however, is like "rm -r directory".
Implementing this will require a way to enumerate the contents of the
directory (and subdirectories).
Another caveat: Due to the way SVN implements branching, a single commit
can have changes from multiple branches. Hopefully no real project does
this.
Related to that (and previously mentioned), it is also possible for
multiple files (on the same branch) in a commit to have the same "parent".
Example:
svn cp a.c b.c
svn commit
Both a.c@tip and b.c@tip will have a.c@(tip - 1) as parent.
About deltas: The way SVN encodes deltas is similar enough to Fossil's
delta encoding that directly converting a SVN delta to a Fossil delta may
be possible. One of the caveats is that in SVN dump files, file artifacts
state which commit the delta is relative to. In Fossil, it appears that the
delta is always relative to the most recent commit updating the file. So it
is possible for SVN to create a delta based on a different commit than
Fossil assumes.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
