Re: [PATCH 0/3] git-cvsserver: Add support for some binary files

[Matthew Ogilvie <mmogilvi_git@miniinfo.net>]

On Mon, May 19, 2008 at 10:34:47AM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 19 May 2008, Matthew Ogilvie wrote:
>
> > I perceive one remaining big issue for git-cvsserver to be a good
> > replacement for real CVS: The ability to properly support "cvs update -r
> > VERSION", where VERSION could be any branch, tag, CVS version number, or
> > git commit hash. Git-cvsserver can partially support this by checking
> > out a totally different sandbox as "cvs checkout VERSION" (notice no
> > -r), but without the ability to switch versions in place, that is an
> > awkward workaround at best.
>
> I might be missing something obvious, but would it not be better to _not_
> check out anything, but serve every object straight from the object
> database (possibly with CR/LF mangling)?

Ah, an opportunity to explain a few things about how git-cvsserver
works generally:

1. git-cvsserver serves most objects straight from the object database
already (actually via git-cat-file), and will continue to do
so.  The exception is when it merges user's changed files
with new versions from the repository, for which git-cvsserver
uses temporary files.

2. git-cvsserver does need to use a temporary git index file for
some things, though.  Usually it is using an empty working
directory with such an index file.  User-modified files get
temporary names that get tracked internally, but it might make
sense for modified .gitattributes files (at least) to be put into the
otherwise empty working directory with the right name so that the
changes effect the current cvs command.

3. CR/LF mangling needs to be done by the CVS client, not the server.
A windows client would do such mangling, while a Linux client would not
(both talking to the same server).  With my patch, the server just
tells the client when a file is binary, so that it won't be
mangled even on windows.

4. git-cvsserver currently does not support the "-r" argument to
checkout or update (to get a particular a branch, a tag, or a
version number).  Instead, as a kind of workaround, it has a hook to
treat the CVS "module" argument (primarily intended to be a
project name in a repository with multiple projects) as a branch
or tag name instead.  But the "module" can't be switched on the fly;
you have to checkout a completely new sandbox to get a different
module (or with git-cvsserver, another branch).

- Matthew Ogilvie