Commits

Augie Fackler  committed 32b6386

First round of thoughts.

  • Participants
  • Parent commits 1d4a642

Comments (0)

Files changed (1)

File hgsubversion/branches.txt

 * 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
+
+AUGIE: I think these three are easy(ish), just with a new branching
+       strategy that's pluggable. The way I'd envision this is that we
+       have some "Layout" abstract base class that could encapsulate
+       the existing standard and single-dir layouts.
+
 * Cleanly add a new branch, whose root may be older than
   last(fromsvn()), to an existing repo
 
+AUGIE: This last requirement is probably really hard. You'll probably
  1. David Schleimer

    Yeah, it is really hard. Unfortunately, the alternative is to put an extra branch and around 500 extra commits in every engineers repo every week. Either that or not support manual conflict resolution when we graft stuff into our release branches.

    I kinda need it but I'm planning to tackle it last and test it really well.

+       want to synthesize a small test repo and test this really thoroughly.
+
 
 Challenges
 ----------
 Paths outside these directories will be handled in the same way that
 standard currently handles them.
 
+AUGIE: This sounds basically reasonable here.
+
 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
 cause the next fetch to partially re-import some svn revisions if said
 revisions affect the new path.
 
+AUGIE: I'm not quite clear how this is different from a configurable
  1. David Schleimer

    The configurable simple layout would still assume something like trunk/branches/tags layout, just with different names.

    Custom layout would allow completely arbitrary svn path to mercurial branch mappings. In this case, it would be something like

    default = prefix/trunk/www
    release-27 = prefix/releases/release-27/www
    

    with only things under those two paths being pulled in. This is what I expect most of our engineers to use since they mostly only care about trunk, and occasionally the current week's release branch when they need to resolve conflicts manually.

    It would allow completely arbitrary layouts like

    default = prefix/trunk/project
    stable = prefix/project/stable
    devel = prefic/branches/user/project
    

    for people with crazy layouts.

    1. Augie Fackler author

      Can you update the doc in your repo to clarify this some? I'm assuming this will be enough work it'll be nice to have the doc to refer to for future self.

+       simple layout? I'm not sure how to express what's not clear for
+       me though.
 
 Alternative Interface
 ---------------------
 believe that we can assume that people using the custom layout will be
 interested in few branches.
 
+AUGIE: This feels like a less-clean implementation.
+
 
 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.
+
+AUGIE: I might be inclined to put it in
+       hgsubversion/strategies/{single_dir,standard,facebook_weirdo,etc}.py
+
 At a minimum, the new library will need to:
 
 * Detect layout when cloning
 It may also be responsible for:
 
 * prefix stripping relative to trunk (and reapplication on commit)
+
+AUGIE: I'm pretty sure it should be responsible for these.
+
 * branch whitelisting
 
 Clone
 the branches we care about, regardless of whether we see new commits
 for that branch.
 
+AUGIE: this all sounds superficially reasonable. I've not thought
+       about it a *whole* lot.