git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ronnie Sahlberg <sahlberg@google.com>
To: git@vger.kernel.org
Cc: Ronnie Sahlberg <sahlberg@google.com>
Subject: [PATCH 0/4] Make update_refs more atomic V2
Date: Thu, 10 Apr 2014 11:30:21 -0700	[thread overview]
Message-ID: <1397154625-11884-1-git-send-email-sahlberg@google.com> (raw)

refs.c:update_refs() intermingles doing updates and checks with actually
applying changes to the refs in loops that abort on error.
This is done one ref at a time and means that if an error is detected that
will fail the operation after only some of the ref operations have been
been updated on the disk.

These patches change the update and delete functions to use a three
call pattern of

1, lock
2, update, or flag for deletion
3, apply on disk

In the final patch I change update_refs to perform these actions in three
separate loops where the final loop to 'apply on disk' all the changes will
only be performed if there were no error conditions detected during any of
previous loops.

This should make the changes of refs in update_refs slightly more atomic.


This may overlap with other current patch series for making refs updates
more atomic which may mean these patches become obsolete, but I would still
like some review and feedback on these changes.

Version 2:
Updates and fixes based on Junio's feedback.
* Fix the subject line for patches so they comply with the project standard.
* Redo the update/delete loops so that we maintain the correct order of
  operations. Perform all updates first, then perform the deletes.
* Add an additional patch that allows us to do the update/delete in the correct
  order from within a single loop by first sorting the refs so that deletes
  are after all non-deletes.


Ronnie Sahlberg (4):
  refs.c: split writing and commiting a ref into two separate functions
  refs.c: split delete_ref_loose() into a separate flag-for-deletion and
    commit phase
  refs.c: change update_refs to run the commit loops once all work is
    finished
  refs.c: sort the refs by new_sha1 and merge the two update/delete
    loops into one

 branch.c               |  10 ++++-
 builtin/commit.c       |   5 +++
 builtin/fetch.c        |   7 +++-
 builtin/receive-pack.c |   4 ++
 builtin/replace.c      |   6 ++-
 builtin/tag.c          |   6 ++-
 fast-import.c          |   7 +++-
 refs.c                 | 102 +++++++++++++++++++++++++++++++++----------------
 refs.h                 |   6 +++
 sequencer.c            |   4 ++
 walker.c               |   4 ++
 11 files changed, 123 insertions(+), 38 deletions(-)

-- 
1.9.1.478.ga5a8238.dirty

             reply	other threads:[~2014-04-10 18:37 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-10 18:30 Ronnie Sahlberg [this message]
2014-04-10 18:30 ` [PATCH 1/4] refs.c: split writing and commiting a ref into two separate functions Ronnie Sahlberg
2014-04-10 18:30 ` [PATCH 2/4] refs.c: split delete_ref_loose() into a separate flag-for-deletion and commit phase Ronnie Sahlberg
2014-04-10 18:30 ` [PATCH 3/4] refs.c: change update_refs to run the commit loops once all work is finished Ronnie Sahlberg
2014-04-10 18:30 ` [PATCH 4/4] refs.c: sort the refs by new_sha1 and merge the two update/delete loops into one Ronnie Sahlberg
2014-04-10 19:01   ` Junio C Hamano
2014-04-10 19:40     ` Ronnie Sahlberg
2014-04-10 18:53 ` [PATCH 0/4] Make update_refs more atomic V2 Junio C Hamano
2014-04-10 20:08   ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1397154625-11884-1-git-send-email-sahlberg@google.com \
    --to=sahlberg@google.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).