David Schleimer committed 4708136

clarify purpose of custom layout, path translation requirements, and clarify layouts classes.

  • Participants
  • Parent commits 1d4a642

Comments (0)

Files changed (1)

File hgsubversion/branches.txt

 * Specify arbitrary directory in which to search for branches.
 * Exclude paths not under trunk/branches dir/tags
-* Specify prefix relative to trunk or ${branch_dir}/${branch_name}
-  that will form the root of commits in Mercurial
+* Specify path relative to trunk or ${branch_dir}/${branch_name}
+  that will be the root of commits in Mercurial
 * Cleanly add a new branch, whose root may be older than
   last(fromsvn()), to an existing repo
 Simple layout would be similar to the current standard layout, with
 the exception that the branches (and possibly tags) dir would be
-configurable, and that it would support a configurable relative
-prefix.  It's possible that the prefix implementation would be better
-off somewhere other than the branch mapping code, I'm not sure yet.
-Paths outside these directories will be handled in the same way that
-standard currently handles them.
+configurable, and that it would support a configurable infix that
+represents the relative path from trunk, or a branches/branchname
+directory to the directory that corresponds to the root of the
+Mercurial repo.  Paths outside these directories will be handled in
+the same way that standard currently handles them.
 Custom layout would accept a map whose keys are mercurial branch
 names, and whose values are non-overlapping svn paths relative to the
 uri we are pulling from.  Changes outside these paths will be ignored
 while importing revisions into Mercurial.  Addition of a new path will
 cause the next fetch to partially re-import some svn revisions if said
-revisions affect the new path.
+revisions affect the new path.  This allows for "sparse" layouts where
+you only want a handful of branches, or for completely arbitrary
+layouts that do not resemble the trunk/branches/tags layout.
 Alternative Interface
 inefiiciently with the number of branches for the custom layout, where
 this wouldn't be reasonable for the default layout.  This is because I
 believe that we can assume that people using the custom layout will be
-interested in few branches.
+interested in few branches.  This approach has been rejected due to
+the consensus that it will be less clean.
 Implementation Strategy
 Right now, the branching logic is spread across at least,, and  The first step is probably to
-centralize this in either, or preferably a new
-At a minimum, the new library will need to:, and  The first step is to pull this logic
+out into a new set of modules under hgsubversion/layouts/ with one
+module for each layout.
+The new library will need to:
 * Detect layout when cloning
 * Translate from a svn path to a mercurial branch name
 * Translate from a Mercurial commit to svn path
-It may also be responsible for:
-* prefix stripping relative to trunk (and reapplication on commit)
-* branch whitelisting
+* Perform path infix stripping on pull and reapplication on push