On Mon, May 19, 2008 at 10:38:21AM +1200, Martin Langhoff wrote:
> On Sat, May 17, 2008 at 12:03 PM, Junio C Hamano <junio@xxxxxxxxx> wrote:
> > Matthew Ogilvie <mmogilvi_git@xxxxxxxxxxxx> writes:
> >
> >> This series of patches extends git-cvsserver to support telling the
> >> CVS client to set the -kb (binary) mode for files that git considers
> >> to be binary (and not for text files). It includes updates to
> >> documentation and tests.
> >
> > I am unfortunately not familiar with this part of the system and I'd need
> > to summon help from experts, but it looks rather nicely done.
>
> IIRC, one thing that is _not_ handled well in CVS -k flag changes on
> the server side (since -k modes are not versioned). If we are
> guessing, this may be more likely to happen, or at least more likely
> to _surprise_ people.
Since git-cvsserver can (and does) refigure and send a different -k
every time it sends a new version of a file, it could be argued
that git-cvsserver actually fixes the non-versioned -k issue,
at least partly, from some perspectives. (There's still the issue
of when a new .gitattributes file takes effect, etc.)
>
> Matthew, have you had a chance to test k mode changes against clients?
> Are we reasonably bug-compatible with the original turd^H^H^Hhing? ;-)
So far I've only done limited testing with Linux CVS 1.12.12.
No newline-munging clients; the test cases just check the
CVS/Entries file, not the file contents. Most of my testing has
been the test cases included with the patch.
I don't expect any new compatibility problems from this. The old code
would send exactly the same data for text files and binary files
as this new code. It was just limited to sending all files as text
or all files as binary (existing gitcvs.allbinary), instead of
allowing a mix.
I'll try to do some newline-munging tests with Cygwin CVS (talking
to a server on Linux) sometime this next week.
I've heard the most finicky CVS client is probably the
one embedded in the Eclipse plugin. Apparently it has had trouble
with minor tweaks in new versions of official CVS, let alone
an emulation. But given that I have never even tried Eclipse, I
probably am not a good choice for testing it, and probably wont.
----------
Generally my motivation here is to make it easier for
an organization like my day job to transition to git. I generally
don't intend to use git-cvsserver myself much, especially not from
platforms that need the newline-munging.
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. Fixing this seems
really involved (extending the DB scheme, etc), unless
clients either treat the CVS version as an opaque string, or
could be easily patched to do so (so that we could just stick
a GIT hash where a CVS version string is expected). Also, some
form of submodule support would also be nice, but not
critical (the right thing here is still vague in my mind,
which is hardly surprising as there has recently been
discussion about awkward use cases for submodules even
within native git itself). Merging with "cvs update -j ..."
and creating tags/branches with CVS are relatively unimportant:
rare enough that they could probably just be reserved for
git itself. Does anyone have any thoughts about any of this?
- Matthew
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
