git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Parkins <andyparkins@gmail.com>
To: git@vger.kernel.org
Subject: [PATCH] New files in git weren't being downloaded during CVS update
Date: Mon, 22 Jan 2007 10:46:12 +0000	[thread overview]
Message-ID: <200701221046.12795.andyparkins@gmail.com> (raw)
In-Reply-To: <200701221044.49467.andyparkins@gmail.com>

If a repository was checked out via git-cvsserver and then later a new
file is added to the git repository via some other method; a CVS update
wasn't fetching the new file.

It would be reported as a new file as
 A some/dir/newfile.c
but would never appear in the directory.

The problem seems to be that git-cvsserver was treating these two cases
identically, as "A" type results.

1. New file in repository
2. New file locally

In fact, traditionally, case 1 is treated as a "U" result, and case 2
only is treated as an "A" result.  "A", should just report that the file
is added locally and then skip that file during an update as their is
(of course) nothing to send.

In both these cases there is no working revision, so the checking for
"is there no working revision" will return true.  The test for case 2
needs refining to say "if there is no working revision and no upstream
revision".  This patch does just that, leaving case 1 to be handled by
the normal "U" handler.

I've also updated the log message to more accurately describe the
operation.  i.e. that "A" means that content is scheduled for addition;
not that it actually has been added.

Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
 git-cvsserver.perl |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index a33a876..2479f71 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -876,9 +876,9 @@ sub req_update
                 print "MT newline\n";
 		next;
 	    }
-	    elsif ( !defined($wrev) || $wrev == 0 )
+	    elsif ( (!defined($wrev) || $wrev == 0) && (!defined($meta->{revision}) || $meta->{revision} == 0) )
 	    {
-	        $log->info("Tell the client the file will be added");
+	        $log->info("Tell the client the file is scheduled for addition");
 		print "MT text A \n";
                 print "MT fname $filename\n";
                 print "MT newline\n";
-- 
1.5.0.rc2.g3f8f2

  reply	other threads:[~2007-01-22 10:46 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-21 14:25 [PATCH] New files in git weren't being downloaded during CVS update Andy Parkins
2007-01-22  2:35 ` Junio C Hamano
2007-01-22  7:02   ` Martin Langhoff
2007-01-22  7:16     ` Junio C Hamano
2007-01-22 10:44 ` Andy Parkins
2007-01-22 10:46   ` Andy Parkins [this message]
2007-01-22 10:56   ` Andy Parkins
2007-01-22 11:08     ` Simon 'corecode' Schubert
  -- strict thread matches above, loose matches on Subject: below --
2007-01-19 10:49 Andy Parkins
2007-01-20  1:19 ` Simon 'corecode' Schubert
2007-01-20 10:25   ` Andy Parkins
2007-01-20 10:41     ` Simon 'corecode' Schubert

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=200701221046.12795.andyparkins@gmail.com \
    --to=andyparkins@gmail.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).