Skip to content
Snippets Groups Projects
  1. Mar 25, 2014
    • durin42's avatar
      tests: add some extra filters for new output · 51b3b3b4927e
      durin42 authored
      Tests pass on both my Mac and Linux machine, so I feel moderately confident
      that this is portable.
      51b3b3b4927e
    • Siddharth Agarwal's avatar
      hg2git: in _init_dirs, store keys without leading '/' (issue103) · 623cb724c3d0
      Siddharth Agarwal authored
      Previously, whenever a tree that wasn't the root ('') was stored, we'd prepend
      a '/' to it. Then, when we'd try retrieving the entry, we'd do so without the
      leading '/'. This caused data loss because existing tree entries were dropped
      on the floor. Fix that by only adding '/' if we're adding to a non-empty
      initial path.
      
      This wasn't detected in tests because most of them deal only with files in the
      root and not ones in subdirectories.
      623cb724c3d0
  2. Mar 15, 2014
    • Siddharth Agarwal's avatar
      hg2git: start incremental conversion from a known commit · 5c7943ca051f
      Siddharth Agarwal authored
      Previously, we'd spin up the Mercurial incremental exporter from the null
      commit and build up state from there. This meant that for the first exported
      commit, we'd have to read all the files in that commit and compute Git blobs
      and trees based on that.
      
      The current Mercurial to Git conversion scheme makes most sense with
      Mercurial's current default storage format, where manifests are diffed against
      the numerically previous revision. At some point in the future, the default
      will switch to generaldelta, where manifests would be diffed against one of
      their parents. In that world it might make more sense to have a stateless
      exporter that diffed each commit against its generaldelta parent and calculated
      dirty trees based on that instead. However, more experiments need to be done to
      see what export scheme is best.
      
      For a repo with around 50,000 files, this brings down an incremental 'hg
      gexport' of one commit from 18 seconds with a hot file cache (and tens of
      minutes with a cold one) to around 2 seconds with a hot file cache.
      5c7943ca051f
    • Siddharth Agarwal's avatar
      git_handler: return early when no commits need to be exported · 4f0a154ae374
      Siddharth Agarwal authored
      This will make our life easier in an upcoming patch.
      4f0a154ae374
    • Siddharth Agarwal's avatar
      hg2git: implement a method to initialize _dirs from a Git commit · d5facc1be5f8
      Siddharth Agarwal authored
      Upcoming patches will start incrementally exporting from a particular commit
      instead of from null. This function will be used for that..
      d5facc1be5f8
  3. Mar 05, 2014
  4. Mar 04, 2014
  5. Feb 28, 2014
  6. Mar 01, 2014
  7. Feb 26, 2014
    • Siddharth Agarwal's avatar
      verify: add new command to verify the contents of a Mercurial rev · 9b194d7c9c03
      Siddharth Agarwal authored
      Since the Git to Mercurial conversion process is incremental, it's at risk of
      missing files, or recording files the wrong way, or recording the wrong commit
      metadata. Add a command called 'gverify' that can verify the contents of a
      particular Mercurial rev against the corresponding Git commit.
      
      Currently, this is limited to checking file names, flags and contents, but this
      can be made as robust as desired. Further additions will probably require
      refactoring git_handler.py a bit though.
      
      This function is pretty fast: on a Linux machine with a warm cache, verifying a
      repository with around 50,000 files takes just 20 seconds. There is scope for
      further improvement through parallelization, but conducting tree walks in
      parallel is non-trivial with the current worker infrastructure in Mercurial.
      9b194d7c9c03
    • Siddharth Agarwal's avatar
      git_handler: remove init_if_missing · cf3bb80a666e
      Siddharth Agarwal authored
      This function is a no-op and can be removed.
      cf3bb80a666e
    • Siddharth Agarwal's avatar
      git_handler: make self.git a lazily evaluated property · 6ab17ae0c834
      Siddharth Agarwal authored
      This allows other functions to be able to use the `git` property without
      needing to care about initializing it.
      
      An upcoming patch will remove the `init_if_missing` function.
      6ab17ae0c834
  8. Feb 25, 2014
    • Siddharth Agarwal's avatar
      overlayrevlog: handle root commits correctly · c99941ff2d28
      Siddharth Agarwal authored
      Previously, we'd try to access commit.parents[0] and fail. Now, check for
      commit.parents being empty and return what Mercurial thinks is a repository
      root in that case.
      c99941ff2d28
    • Siddharth Agarwal's avatar
      overlayrevlog: handle rev = 0 correctly · aa8519daf037
      Siddharth Agarwal authored
      Previously we'd just test if gitrev was falsy, which it is if the rev returned
      is 0, even though it shouldn't be. With this patch, test against None
      explicitly.
      
      This unmasks another bug: see next patch for a fix and a test.
      aa8519daf037
  9. Feb 24, 2014
    • Siddharth Agarwal's avatar
      git_handler: fix call to self.ui.progress in flush · 1323058cc652
      Siddharth Agarwal authored
      Since we now directly use progress on self.ui, we shouldn't pass in self.ui as
      the first argument. Oops.
      1323058cc652
    • Siddharth Agarwal's avatar
      git_handler: don't compute tags for each tag imported · 7ca655e44d9a
      Siddharth Agarwal authored
      Previously we'd recompute the repo tags each time we'd consider importing a Git
      tag. This is O(n^2) in the number of tags and produced noticeable slowdowns in
      repos with large numbers of tags.
      
      To fix this, compute the tags just once. This is correct because the only case
      where we'd have issues is if multiple new Git tags with the same name were
      introduced, which can't happen because Git tags cannot share names.
      
      For a repository with over 200 tags, this causes a no-op hg pull to be sped up
      by around 0.5 seconds.
      7ca655e44d9a
  10. Feb 20, 2014
  11. Feb 19, 2014
  12. Feb 20, 2014
    • Siddharth Agarwal's avatar
      tests: upgrade run-tests.py · 0b33ab75e3cb
      Siddharth Agarwal authored
      This is the version in Mercurial rev 87e52e642562, plus a patch to make
      --with-hg work for system hg (sent upstream). Importantly, this gets us the
      hash seed randomization we need for bugs like the one fixed by the parent
      commit to be detected.
      0b33ab75e3cb
    • Siddharth Agarwal's avatar
      hg2git: fix subrepo handling to be deterministic · fbfa6353d96c
      Siddharth Agarwal authored
      Previously, the correctness of _handle_subrepos was based on the order the
      files were processed in. For example, consider the case where a subrepo at
      location 'loc' is replaced with a file at 'loc', while another subrepo exists.
      This would cause .hgsubstate and .hgsub to be modified and the file added.
      
      If .hgsubstate was seen _before_ 'loc' in the modified/added loop, then
      _handle_subrepos would run and remove 'loc' correctly, before 'loc' was added
      back later. If, however, .hgsubstate was seen _after_ 'loc', then
      _handle_subrepos would run after 'loc' was added and would remove 'loc'.
      
      With this patch, _handle_subrepos merely computes the changes that need to be
      applied. The changes are then applied, making sure removed files and subrepos
      are processed before added ones.
      
      This was detected by setting a random PYTHONHASHSEED (in this case, 3910358828)
      and running the test suite against it. An upcoming patch will randomize the
      PYTHONHASHSEED in run-tests.py, just like is done in Mercurial.
      fbfa6353d96c
Loading