Revision adc446fe5d5f6dc1fb5edeaa9aa016ef94e70da1 authored by Junio C Hamano on 08 October 2006, 19:56:19 UTC, committed by Junio C Hamano on 09 October 2006, 00:13:15 UTC
Sean <seanlkml@sympatico.ca> writes: > On Sat, 07 Oct 2006 21:52:02 -0700 > Junio C Hamano <junkio@cox.net> wrote: > >> Using DAV, if it works with the server, has the advantage of not >> having to keep objects/info/packs up-to-date from repository >> owner's point of view. But the repository owner ends up keeping >> up-to-date as a side effect of keeping info/refs up-to-date >> anyway (as I do not see a code to read that information over >> DAV), so there is no point doing this over DAV in practice. >> >> Perhaps we should remove call to remote_ls() from >> fetch_indices() unconditionally, not just protected with >> NO_EXPAT and be done with it? > > That makes a lot of sense. A server really has to always provide > a objects/info/packs anyway, just to be fetchable today by clients > that are compiled with NO_EXPAT. And even for an isolated group where everybody knows that everybody else runs DAV-enabled clients, they need info/refs prepared for ls-remote and git-fetch script, which means you will run update-server-info to keep objects/info/packs up to date. Nick, do you see holes in my logic? -- >8 -- http-fetch.c: drop remote_ls() While doing remote_ls() over DAV potentially allows the server side not to keep objects/info/pack up-to-date, misconfigured or buggy servers can silently ignore or not to respond to DAV requests and makes the client hang. The server side (unfortunately) needs to run git-update-server-info even if remote_ls() removes the need to keep objects/info/pack file up-to-date, because the caller of git-http-fetch (git-fetch) and other clients that interact with the repository (e.g. git-ls-remote) need to read from info/refs file (there is no code to make that unnecessary by using DAV yet). Perhaps the right solution in the longer-term is to make info/refs also unnecessary by using DAV, and we would want to resurrect the code this patch removes when we do so, but let's drop remote_ls() implementation for now. It is causing problems without really helping anything yet. git will keep it for us until we need it next time. Signed-off-by: Junio C Hamano <junkio@cox.net>
1 parent 9a7a62f
test-delta.c
/*
* test-delta.c: test code to exercise diff-delta.c and patch-delta.c
*
* (C) 2005 Nicolas Pitre <nico@cam.org>
*
* This code is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/mman.h>
#include "delta.h"
static const char usage[] =
"test-delta (-d|-p) <from_file> <data_file> <out_file>";
int main(int argc, char *argv[])
{
int fd;
struct stat st;
void *from_buf, *data_buf, *out_buf;
unsigned long from_size, data_size, out_size;
if (argc != 5 || (strcmp(argv[1], "-d") && strcmp(argv[1], "-p"))) {
fprintf(stderr, "Usage: %s\n", usage);
return 1;
}
fd = open(argv[2], O_RDONLY);
if (fd < 0 || fstat(fd, &st)) {
perror(argv[2]);
return 1;
}
from_size = st.st_size;
from_buf = mmap(NULL, from_size, PROT_READ, MAP_PRIVATE, fd, 0);
if (from_buf == MAP_FAILED) {
perror(argv[2]);
close(fd);
return 1;
}
close(fd);
fd = open(argv[3], O_RDONLY);
if (fd < 0 || fstat(fd, &st)) {
perror(argv[3]);
return 1;
}
data_size = st.st_size;
data_buf = mmap(NULL, data_size, PROT_READ, MAP_PRIVATE, fd, 0);
if (data_buf == MAP_FAILED) {
perror(argv[3]);
close(fd);
return 1;
}
close(fd);
if (argv[1][1] == 'd')
out_buf = diff_delta(from_buf, from_size,
data_buf, data_size,
&out_size, 0);
else
out_buf = patch_delta(from_buf, from_size,
data_buf, data_size,
&out_size);
if (!out_buf) {
fprintf(stderr, "delta operation failed (returned NULL)\n");
return 1;
}
fd = open (argv[4], O_WRONLY|O_CREAT|O_TRUNC, 0666);
if (fd < 0 || write(fd, out_buf, out_size) != out_size) {
perror(argv[4]);
return 1;
}
return 0;
}
Computing file changes ...
