1. 08 Jun, 2018 2 commits
  2. 05 Jun, 2018 1 commit
  3. 25 Apr, 2018 1 commit
    • Alain Takoudjou's avatar
      gitlab-backup: don't keep backup_gitlab.pulled files · 0b8d834b
      Alain Takoudjou authored
      add option to remove or keep pulled backup data
      
      [ kirr: The .pulled files with gitlab backup data (SQL and the like)
        were originally not removed "just in case" in the early days of
        git/gitlab-backup. They are clearly not needed to be kept since their
        content is entered into git backup database by gitlab-backup, and
        leaving those .pulled files just wastes disk space.
      
        So default to not keep them around and for now add an option to
        forcibly preserve the raw gitlab backup if we'll need it just in case or
        for the debugging.
      
        However if it turns out we won't really need -keep in practice, it
        might go away in some time. ]
      
      /reviewed-on !3
      0b8d834b
  4. 07 Mar, 2018 1 commit
  5. 24 Oct, 2017 1 commit
    • Kirill Smelkov's avatar
      Relicense to GPLv3+ with wide exception for all Free Software / Open Source... · e37d99b4
      Kirill Smelkov authored
      Relicense to GPLv3+ with wide exception for all Free Software / Open Source projects + Business options.
      
      Nexedi stack is licensed under Free Software licenses with various exceptions
      that cover three business cases:
      
      - Free Software
      - Proprietary Software
      - Rebranding
      
      As long as one intends to develop Free Software based on Nexedi stack, no
      license cost is involved. Developing proprietary software based on Nexedi stack
      may require a proprietary exception license. Rebranding Nexedi stack is
      prohibited unless rebranding license is acquired.
      
      Through this licensing approach, Nexedi expects to encourage Free Software
      development without restrictions and at the same time create a framework for
      proprietary software to contribute to the long term sustainability of the
      Nexedi stack.
      
      Please see https://www.nexedi.com/licensing for details, rationale and options.
      e37d99b4
  6. 19 Apr, 2017 1 commit
  7. 13 Dec, 2016 4 commits
  8. 03 Nov, 2016 1 commit
    • Kirill Smelkov's avatar
      Don't be fooled by strings.Split(..., "\n") result always having empty "" last element · 3ba6cf73
      Kirill Smelkov authored
      By definition of strings.Split(..., sep) it "slices s into all substrings
      separated by sep and returns a slice of the substrings between those
      separators". That means that
      
          string.Split("hello\nworld\n", "\n") -> ["hello", "world", ""])     # NOTE the last ""
      
      when parsing file by lines, it is handy though to do not get last empty
      "" after last "\n". #6 shows how we missed to do that filtering-out for
      case of empty backup.refs file and errored-out because of that.
      
      To fix let's introduce a helper - splitlines(), which does the job of
      filtering-out last empty entry after last separator. By using this
      helper everywhere we can hopefully avoid problems while pulling only
      empty repositories (#6 case), and also similar ones.
      
      Fixes #6
      /reported-by @iv
      3ba6cf73
  9. 01 Aug, 2016 3 commits
    • Kirill Smelkov's avatar
      pull: Don't let a lot of empty directories stay under refs/backup/... work prefix after end of pull · 7535343c
      Kirill Smelkov authored
      Continuing 62374038 (pull: Turns unused refs are removed not 100% and a
      lot of empty directories are accumulated) we just make sure to remove
      them in the end of pull.
      
      But NOTE: there could be O(n^2) behaviour still hidden, so it makes
      sense to eventually revisit it and cleanup empty dirs earlier.
      
      For now we just care not to degrade future pull performance. The
      appropriate time for revisiting could be when reworking pull to do
      fetches in parallel.
      
      Updates: https://lab.nexedi.com/lab.nexedi.com/lab.nexedi.com/issues/4
      7535343c
    • Kirill Smelkov's avatar
      restore: Extract packs in multiple workers · ff2f0b67
      Kirill Smelkov authored
      This way it allows us to leverage multiple CPUs on a system for pack
      extractions, which are computation-heavy operations.
      
      The way to do is more-or-less classical:
      
          - main worker prepares requests for pack extraction jobs
      
          - there are multiple pack-extraction workers, which read requests
            from jobs queue and perform them
      
          - at the end we wait for everything to stop, collect errors and
            optionally signalling the whole thing to cancel if we see an error
            coming. (it is only a signal and we still have to wait for
            everything to stop)
      
      The default number of workers is N(CPU) on the system - because we spawn
      separate `git pack-objects ...` for every request.
      
      We also now explicitly limit N(CPU) each `git pack-objects ...` can use
      to 1. This way control how many resources to use is in git-backup hand
      and also git packs better this way (when only using 1 thread) because
      when deltifying all objects are considered to each other, not only all
      objects inside 1 thread's object poll, and even when pack.threads is not
      1, first "objects counting" phase of pack is serial - wasting all but 1
      core.
      
      On lab.nexedi.com we already use pack.threads=1 by default in global
      gitconfig, but the above change is for code to be universal.
      
      Time to restore nexedi/ from lab.nexedi.com backup:
      
      2CPU laptop:
      
          before (pack.threads=1)     10m11s
          before (pack.threads=NCPU)   9m13s
          after  -j1                  10m11s
          after                        6m17s
      
      8CPU system (with other load present, noisy) :
      
          before (pack.threads=1)     ~5m
          after                       ~1m30s
      ff2f0b67
    • Kirill Smelkov's avatar
      raisef: Fix it wrt erraddcallingcontext() · 6c2abbbf
      Kirill Smelkov authored
      like in 302aaaea (raiseif: Fix it wrt erraddcallingcontext()) now fix
      raisef, which I originally overlooked.
      6c2abbbf
  10. 31 Jul, 2016 3 commits
    • Kirill Smelkov's avatar
      xcommit_tree: Teach it to create commit without spawning `git commit-tree ...` · 3a7b390c
      Kirill Smelkov authored
      Because spawning separate process per 1 commit is slow.
      
      Libgit2 does not allow to create commits only knowing tree & parentv
      sha1s, but we can create commit objects by hand pretty easily - their format is
      
          tree <sha1>
          parent <parent1-sha1>
          parent <parent2-sha1>
          ...
          author user <email> date +offset
          committer user <email> date +offset
          LF
          message
      
      Time for pulling-in kirr/slapos.git
      
      before: 2.5s
      after:  0.9s
      
      NOTE AuthorInfo is changed to inherit from git.Signature (same fields
          and semantic)
      
      NOTE Since libgit2 default ident can fail, and does not look beyond
          user.name and user.email we do backup identity detection
          (user/hostname) - in similar way Git does - ourselves.
      3a7b390c
    • Kirill Smelkov's avatar
      Move xcommit_tree() & friends to gitobjects.go · cc450765
      Kirill Smelkov authored
      We are going to rework this function, but before adding changes let's
      move it to more appropriate place. Since xcommit_tree() creates commit
      object from tree and parents and is pretty standard git function - the
      appropriate place is gitobjects.
      
      NOTE we cannot just replace xcommit_tree() with g.CreateCommit() as the
          latter works with already loaded tree and parent objects, but we
          want to be able to make commits only knowing tree and parents sha1.
      cc450765
    • Kirill Smelkov's avatar
      Verify tag/tree/blob encoding is consistent and always the same · 5aac4734
      Kirill Smelkov authored
      In upcoming patch we are going to switch xcommit_tree() to our own
      implementation, and since this can potentially change how commits are
      represented, for backward compatibility reason we need to make sure
      objects encoded as commits stay the same.
      
      So for all kind of objects (they are present in testdata/ repositories)
      add checks that:
      
          - encode/decode is idempotent
          - encoding and decoding produces exactly expected sha1
      
      One nice side effect of this is that we can now remove runtime
      consistency check from tail of decoding. That check was there from the
      beginning - from 6f237f22 (git-backup: Initial draft) mainly present
      because there was no testsuite at that time. That check place is however
      even not completely right - in case we somehow wrongly pulled an object
      it has to be detected at pull time, not restore time. So that check was
      checking only 1/2 of implementation - and not the main one - that
      decoding does not mess up.
      
      Since now we have proper testsuite and add encode/decode tests in this
      patch, we can remove that partial runtime check. And even if decoding
      messes something up, despite having it testsuited, it will be 100%
      caught by restore process, because for an extracted repository, if
      there is no some object which needs to be present in it, pack generation
      for that repository will fail. So we can be safe with the removal.
      
      Time for restoring kirr/slapos.git from lab.nexedi.com backup
      
      before: 5.5s
      after:  3.5s
      
      ( so much because there are ~ 500 tags in slapos.git and currently tag
        encoding is done with spawning separate subprocess per tag )
      5aac4734
  11. 30 Jul, 2016 1 commit
    • Kirill Smelkov's avatar
      pull: Add blobs to index in batch · dbf86b19
      Kirill Smelkov authored
      Do not waste resources adding every file converted to blob with spawning
      `git update-index ...` per file - we can queue the info and add all
      entries to index in one go.
      
      Time to pull files part for lab.nexedi.com
      
      before: ~110s
      after:    ~3s
      dbf86b19
  12. 29 Jul, 2016 6 commits
    • Kirill Smelkov's avatar
      obj_recreate_from_commit: Re-create tag without spawning hash-object · c33dc392
      Kirill Smelkov authored
      Time for restoring kirr/slapos.git from lab.nexedi.com backup
      
      before: 7.4s
      after:  5.6s
      c33dc392
    • Kirill Smelkov's avatar
      Switch xload_tag() too work without spawning Git subprocess · 5b1cdca3
      Kirill Smelkov authored
      We can reuse ReadObject() like for blob_to_file().
      
      We cannot drop xload_tag() in favor of Repository.LookupTag() because
      upon tag loading we need to have not only parsed tag, but also its raw
      content for encoding in another object.
      
      Time for restoring kirr/slapos.git from lab.nexedi.com backup
      
      before: 8.9s
      after:  7.4s
      
      ( it goes down because on restore restored tags are reencoded again to
        verify restoration was ok. Pulling time should go down appropriately
        as well )
      5b1cdca3
    • Kirill Smelkov's avatar
      Switch file_to_blob() and blob_to_file() to work without spawning Git subprocesses · fbd72c02
      Kirill Smelkov authored
      Substituting `git cat-file` to Odb.Read() and `git hash-object -w` to
      Odb.Write().
      
      Timing for restoring only files from lab.nexedi.com backup:
      
      before: ~95s
      after:   ~8s
      
      Timings for making backup in file part should have similar effect.
      fbd72c02
    • Kirill Smelkov's avatar
      Drop xload_commit() in favor of git2go's Repository.LookupCommit() · 87283e4b
      Kirill Smelkov authored
      This saves us one `git cat-file` call per recreated tag.
      
      Time for restoring kirr/slapos.git from lab.nexedi.com backup
      
      before: 10.3s
      after:   8.9s
      87283e4b
    • Kirill Smelkov's avatar
      Hook in git2go (cgo bindings to libgit2) · 624393db
      Kirill Smelkov authored
      Currently for every file -> blob, and blob -> file we invoke git
      subprocess (cat-file or hash-object). We also invoke git subprocess for
      every tag read/write and the same for commits and this 1-subprocess per
      1 object has very high overhead.
      
      The ways to avoid such overhead could be:
      
      1) for every kind of operation spawn git service process, like e.g.
         `git cat-file --batch` for reading files, and only do request/reply
         per object with it.
      
      2) use some go library to work with git repository ourselves.
      
      "1" can work but:
      
          - at present there is no counterpart of `cat-file --batch` for
            e.g. `hash-object` - i.e. we cannot write objects without quirks
            or patching git.
      
          - even if we add support for hashing via request/reply, as all
            requests are processed sequentially on git side by e.g. `git
            cat-file --batch`, we won't be able to leverage parallelism.
      
          - request/reply has also latency attached.
      
      For "2" we have roughly the following choices:
      
          - use cgo bindings to libgit2   (git2go)
      
          - use some pure-go git library
      
      Pure-go approach has pros that it by design avoids problems related to
      tricky CGo pointer C <-> Go passing rules. The fact that this was sorted
      out by go team itself only during 1.6 cycle
      
          https://github.com/golang/go/issues/12416
      
      tells a lot. The net is full of examples where those were hard to get,
      and git2go in particular has a story of e.g. heap corruption (the bug
      was on golang itself side and fixed only for 1.5)
      
          https://github.com/libgit2/git2go/issues/223
          https://groups.google.com/forum/#!topic/golang-nuts/Vi1HD-54BTA/discussion
      
      However there is no good (to my knowledge) pure-go git library, and the
      family of forks around github.com/speedata/gogit either:
      
          - works 3x slower compared to git2go
      
            ( or the same 3x in serial mode compared to e.g. `git cat-file --batch`
              as in serial mode git subservice and git2go has roughly similar performance )
      
          - or does not work at all (e.g. barfing out on REF_DELTA pack
            entries, etc)
      
      So because of 3x slowdown, pure-go way is currently a no-runner.
      
      Since one person from golang team cared to update git2go to properly
      follow the CGo rules
      
          https://github.com/libgit2/git2go/pull/282
      
      we can be relatively confident about git2go bindings quality and try to
      use it.
      
      This commit only hooks git2go into the build, subcommands and to Sha1
      for to/from Oid conversion. We'll be switching places to git2go
      incrementally in upcoming patches.
      
      NOTE for now we need git2go from next branch for
      
          https://github.com/libgit2/git2go/commit/cf7553e7
      
      The plan is to eventually switch to
      
          gopkg.in/libgit2/git2go.v25
      
      once it is out.
      624393db
    • Kirill Smelkov's avatar
      Rename git() -> ggit() · fdaa4a19
      Kirill Smelkov authored
      We are going to use git2go (see next patch) for which canonical import
      path is git (import "github.com/libgit2/git2go" results in package name
      being autotruncated to just "git") so free up the "git" name for that
      package.
      
      Reason is: git() - as function - is used not often, while the package
      will be used often.
      
      Regarding naming: not sure it is good choice but ggit() is something
      like xgit(), only g is for "GitError".
      fdaa4a19
  13. 27 Jul, 2016 1 commit
  14. 25 Jul, 2016 1 commit
    • Kirill Smelkov's avatar
      error/mypkgname: Fix for a package living under dotted prefix · 36da74e6
      Kirill Smelkov authored
      In 28986e0e (Rewrite in Go) I've added mypkgname() with comment that go
      escapes all '.' in function name with %2e. That turned out to be not
      true: Go escapes only dots in last component after last slash, e.g.
      
          lab.nexedi.com/kirr/git-backup/package%2ename.Function
          lab.nexedi.com/kirr/git-backup/pkg2.qqq/name%2ezzz.Function
      
      Correct mypkgname() accordingly.
      
      Noted while trying to run git-backup in a GOPATH root, not as
      standalone.
      36da74e6
  15. 07 Jul, 2016 2 commits
  16. 06 Jul, 2016 2 commits
    • Kirill Smelkov's avatar
      obj_represent_as_commit is always called with obj_type non-empty · b8bd89a3
      Kirill Smelkov authored
      It was a default leftover to autodetect object type if obj_type=None,
      from the beginning - from bbee44ce (Start of git-backup.git) - because
      even there obj_represent_as_commit() is always called with obj_type
      explicitly passed in.
      
      So remove the leftover.
      b8bd89a3
    • Kirill Smelkov's avatar
      Rewrite in Go · 28986e0e
      Kirill Smelkov authored
      This is more-or-less 1-to-1 port of git-backup to Go. There are things
      we handle a bit differently:
      
      - there is a separate type for Sha1
      - conversion of repo paths to git references is now more robust wrt
        avoiding not-allowed in git constructs like ".." or ".lock"
      
        https://git.kernel.org/cgit/git/git.git/tree/refs.c?h=v2.9.0-37-g6d523a3#n34
      
      The rewrite happened because we need to optimize restore, and for e.g.
      parallelizing part it should be convenient to use goroutines and channels.
      
      I'm not very comfortable with how error handling is done, because
      contrary to what canonical Go way seems to be, in a lot of places it still
      looks to me exceptions are better idea compared to just error codes,
      though in many places just error codes are better and makes more sense.
      Probably there will be less exceptions over time once the code starts to
      be collaborating set of goroutines with communications done via
      channels.
      
      Still a lot of python habits on my side.
      
      And as a bonus we now have end-to-end pull/restore tests...
      28986e0e
  17. 20 Jun, 2016 2 commits
  18. 13 Jun, 2016 1 commit
  19. 02 May, 2016 1 commit
  20. 13 Apr, 2016 2 commits
  21. 29 Feb, 2016 1 commit
  22. 28 Feb, 2016 1 commit
    • Kirill Smelkov's avatar
      gitlab-backup/restore: Don't allow ln ambiguity (which can lead to failures) · 7279754d
      Kirill Smelkov authored
      ln has several syntaxes. man ln 1 ln:
      
         SYNOPSIS
                ln [OPTION]... [-T] TARGET LINK_NAME   (1st form)
                ln [OPTION]... TARGET                  (2nd form)
                ln [OPTION]... TARGET... DIRECTORY     (3rd form)
                ln [OPTION]... -t DIRECTORY TARGET...  (4th form)
      
      so without -T or -t what is target and what is link name is ambiguous and
      ln tries to guess. Now imagine:
      
          ln -sf /path/to/new/hook    $H
      
      and let us consider that $H is already a symlink, pointing to some place
      which _exists_, but current user do not have access to. Then ln will
      complain:
      
          ln: accessing `$H': Permission denied
      
      and abort.
      
      Fix it by specifying ln form we use explicitly with -T.
      7279754d
  23. 10 Feb, 2016 1 commit
    • Kirill Smelkov's avatar
      Make sure git will recognize *.git as repositories, even empty ones, after restore · b770b689
      Kirill Smelkov authored
      On restore we were initializing refs/ and objects/ for repositories
      obtained from backuped refs set, but this approach does not cover empty
      repositories - e.g. repositories without any ref at all.
      
      A frequent case for this is *.wiki.git in gitlab, and if we restore only
      files for such repo, without empty refs/ and objects/ it would look like
      restored ok, but any git-related operation on such repo will fail.
      
      Fix it via making sure to create refs/ and objects/ the first time we
      see a *.git while restoring files.
      
      /cc @kazuhiko
      b770b689