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
+replace standard with a new simple mode, and add a third ustom 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. s 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
ing hte new path.
+revisions affecte new path.
+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.
+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)
+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
+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
+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