1. David Schleimer
  2. scratch-notes


David Schleimer  committed 1d4a642


  • Participants
  • Parent commits 07d8dcf
  • Branches default

Comments (0)

Files changed (1)

File hgsubversion/branches.txt

View file
 branches.  Instead we want developers to be able to add individual
 branches to their repository as nedded.
+While this particular layout is unique to our repository, we believe the problem we are facing is not.  We would rather add sufficient flexibilty to the upstream to cover our needs than build a custom extension in-house.
 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.
+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
 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
+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 affecting hte new path.
+revisions affect the new path.
+Alternative Interface
+Rather than having a custom layout, we could add support for a branch
+whitelist to the simple layout, which would serve our needs.  I
+believe that this is likely to be harder to implement than a separate
+custom layout.  Specifically, I believe that backfilling a new branch
+will be much harder, in particular since we can afford to scale
+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.
+Implementation Strategy
+Right now, the branching logic is spread across at least pushmod.py,
+svncommads.py, and svnmeta.py.  The first step is probably to
+centralize this in either svnmets.py, or preferably a new pathtranslation.py.
+At a minimum, 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
+The exact set of flags -> config settings clone processes will change
+to support the new layouts, but it's behavior will not otherwise
+Very little will change for the simple and the single cases, mostly
+just refactoring.
+For the custom case, we will need to find the lowest last fetched
+revision for any branch.  If there is a branch which does not have a
+last fetched revision, we will need to attempt to detect the creation
+revision for that branch, similar to what we would need to do during
+an intial clone.  We then replay revisions from that commit onward,
+discarding changes which touch files outside the paths we care about,
+or that map to a branch for which we have already fetched the revision
+in question.
+Note that for this to be effective, we need to update the last pulled
+revision for a branch every time we pull revisions and include it in
+the branches we care about, regardless of whether we see new commits
+for that branch.