On Wed, Oct 15, 2014 at 4:54 PM, Ron W <ronw.m...@gmail.com> wrote: > But that's just the executive summary. The details will require much > research, planning and design. >
After doing some research, I was reminded that SVN branches (and tags) are implemented as copy-by-reference. This means that the definition of a branch is by convention, not by an explicit action. For a project that follows the recommended convention of directories named "trunk", "branches" and "tags" - or clearly identifies its convention - creating branches (and tagged commits) in Fossil should not be too hard. If the convention cannot be identified, then no branches would be created. For non-branch, non-tag copy (whether by reference or not), I'm not sure how to handle. Per SVN Dump documentation, a copy adds a new artifact that retains the history of the artifact it was copied from. The new artifact will have its own path/name. The semantics described for the F card imply using the fourth field means a rename or move was done. I'm not sure what Fossil would do when (if?) the F card is used to represent this clone-then-rename-the-clone operation. I suppose SVN could represent a rename/move as a copy followed by delete of the original artifact. A question about libfossil: Is it possible to directly create a delta artifact? I ask this because it looks like SVN::Dump::Reader does not un-delta the artifact content. So either I would have to apply the delta myself (to provide the full text to libfossil) or convert the SVN delta into a Fossil delta.
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
