1. David Schleimer
  2. scratch-notes


David Schleimer  committed 07d8dcf

Motivation, Requirements, and Interface

  • Participants
  • Branches default

Comments (0)

Files changed (1)

File hgsubversion/branches.txt

View file
+This document describes a plan for addressing one of the current
+limitations of hgsubversion.  Specifically, that it is limited to a
+single path within a subversion repository.
+Facebook is in the process of migrating from a mixed git/svn
+environment to a Mercurial environment, via a mixed hg/svn
+environment.  One of the requirements for our migration is that we
+make our release branches available via Mercurial, both as a whole in
+the central repository, and individually to developers.
+Our repository HEAD is structured something like this:
+  trunk/
+    www/
+  releases/
+    release-1/
+      www/
+    release-2/
+      www/
+  latest/
+Additionally, there are historical directories at the same level as
+trunk and releases (notably including branches), which do not
+currently exist, but which are involved in the history of trunk.  We
+are mostly uninterested in these directories, aside from their
+contributions to the history of trunk.
+There is a svn:externals property on the latest directory that is
+updated to point to one of the www directories under releases every
+time a new release is created.  We are uninterested in this directory
+beyond ensuring it is not present in Mercurial.
+We currently have a mercurial clone in single mode of
+prefix/trunk/www.  We want to add a Mercurial branch for each of the
+releases in a central repo.  We do not want all developers to have a
+copy of all the branches, since most developers will never need most
+branches.  Instead we want developers to be able to add individual
+branches to their repository as nedded.
+* 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
+* Cleanly add a new branch, whose root may be older than
+  last(fromsvn()), to an existing repo
+* We currently track a single most recently pulled rev, which makes it
+  difficult to retroactively add a branch
+* 'branches/' is hard-coded in many locations
+Proposed Interface
+Currently there are two layouts: single, and standard.  I would like to
+replace standard with a new simple mode, and add a third Custom layout.
+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.
+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.  Paths 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 affecting hte new path.