git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: Martin Langhoff <martin@catalyst.net.nz>
Cc: junkio@cox.net, git@vger.kernel.org
Subject: Re: [PATCH] cvsimport: skip commits that are too recent
Date: Sun, 07 Jan 2007 17:59:38 -0800	[thread overview]
Message-ID: <7virfiz3at.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <1168218683853-git-send-email-martin@catalyst.net.nz> (Martin Langhoff's message of "Mon, 8 Jan 2007 14:11:23 +1300")

Martin Langhoff <martin@catalyst.net.nz> writes:

> With this patch, cvsimport will skip commits made
> in the last 10 minutes. The recent-ness test is of
> 5 minutes + cvsps fuzz window (5 minutes default).
>
> When working with a CVS repository that is in use,
> importing commits that are too recent can lead to
> partially incorrect trees. This is mainly due to
>
>  - Commits that are within the cvsps fuzz window may later
>    be found to have affected more files.
>
>  - When performing incremental imports, clock drift between
>    the systems may lead to skipped commits.

Hmmmmm.  This is good for tracking other people's work, but, I
am not quite sure how well it works with my workflow.

I have a CVS upstream, but I manage my own development with git.
I start my day by running an incremental cvsimport, rebase my
branch on top of whatever at the tip of the cvsimport branch.  I
use cvsexportcommit (actually a moral equivalent of it I've been
using before cvsexportcommit has become part of git) to make
parts of my branch that are ready for other people's consumption
available by making commits on the CVS side.  Almost immediately
after that, I do another incremental cvsimport so that I can
rebase the remainder of my branch on top of what I made public.

I guess there is no negative impact your patch has on me -- this
10 minute window does not mean that I cannot continue working.
I can keep working on my stuff on my (old) branch without the
second cvsimport and rebase and there is nothing lost.  I can do
the second cvsimport and rebase later.

Which means that you did not give me a new excuse to take a
coffee break and work on git stuff instead of my day job project
to my management but that is Ok.  I'll find other ways ;-).

  reply	other threads:[~2007-01-08  1:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-08  1:11 [PATCH] cvsimport: skip commits that are too recent Martin Langhoff
2007-01-08  1:59 ` Junio C Hamano [this message]
2007-01-08  2:13   ` Martin Langhoff
2007-01-08  2:19     ` Junio C Hamano
2007-01-08  3:18       ` Martin Langhoff
  -- strict thread matches above, loose matches on Subject: below --
2007-01-08  6:43 Martin Langhoff
2007-01-08  7:17 ` Martin Langhoff
2007-01-08  8:24   ` Martin Langhoff
2007-01-11  8:22 ` Robin Rosenberg
2007-01-11 20:18   ` Martin Langhoff

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=7virfiz3at.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=git@vger.kernel.org \
    --cc=martin@catalyst.net.nz \
    /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).