git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Ori Rawlings <orirawlings@gmail.com>
To: Lars Schneider <larsxschneider@gmail.com>
Cc: git@vger.kernel.org, Vitor Antunes <vitor.hda@gmail.com>,
	Luke Diamand <luke@diamand.org>, Pete Wyckoff <pw@padd.com>
Subject: Re: [PATCH v2 1/1] git-p4: Add --checkpoint-period option to sync/clone
Date: Fri, 16 Sep 2016 12:43:26 -0500	[thread overview]
Message-ID: <CAPv0x+OB=6ju90unOnChXLK-tbYt0utV5JsguE-Dw9zbd28siA@mail.gmail.com> (raw)
In-Reply-To: <9A490197-3220-4AF9-95DA-89B726A91F92@gmail.com>

On Fri, Sep 16, 2016 at 11:19 AM, Lars Schneider
<larsxschneider@gmail.com> wrote:
>
>
> This looks interesting! I ran into the same issue and added a parameter to the p4 commands to retry (patch not yet proposed to the mailing list):
> https://github.com/autodesk-forks/git/commit/fcfc96a7814935ee6cefb9d69e44def30a90eabb

I was unaware of the retry flag to the p4 command, that seems like a
useful trick too. I think both approaches might pair nicely together
(p4 optimistically retrying, but still falling back to the latest git
checkpoint if we exhaust our N retry attempts).

> Would it make sense to print the "git-p4 resume command" in case an error happens and checkpoints are written?

I was thinking something like this would be a good idea and would
certainly aide in usability. Resuming a sync is fairly
straight-forward (just re-execute the same command). Resuming a clone
is a bit more problematic, today if a depot path argument is provided
to the sync or clone command (and it is always required for clone), no
attempt is made to examine the existing git branches and limit to only
Perforce changes missing from git.

There is a lingering TODO in the script where we check the presence of
the depot path argument, with a suggestion that we should always make
an attempt to continue building upon existing history when it is
available. I think there might be a few edge cases around this
behavior that I'd need to think through. But, if I'm able to address
the TODO, then printing the command to resume the import should be
pretty straight-forward. I'll continue working on that next week.

      reply	other threads:[~2016-09-16 17:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-12 22:02 [PATCH] [git-p4.py] Add --checkpoint-period option to sync/clone Ori Rawlings
2016-09-12 22:02 ` Ori Rawlings
2016-09-13  8:10   ` Luke Diamand
2016-09-15 21:17 ` [PATCH v2 0/1] git-p4: " Ori Rawlings
2016-09-15 21:17   ` [PATCH v2 1/1] " Ori Rawlings
2016-09-16 16:19     ` Lars Schneider
2016-09-16 17:43       ` Ori Rawlings [this message]

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to='CAPv0x+OB=6ju90unOnChXLK-tbYt0utV5JsguE-Dw9zbd28siA@mail.gmail.com' \
    --to=orirawlings@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=larsxschneider@gmail.com \
    --cc=luke@diamand.org \
    --cc=pw@padd.com \
    --cc=vitor.hda@gmail.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).