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

["Martin Langhoff" <martin.langhoff@gmail.com>]

On Mon, May 19, 2008 at 7:35 PM, Matthew Ogilvie
<mmogilvi_git@miniinfo.net> wrote:
> 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.

Indeed. We've had endless trouble with Eclipse :-(

> 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.

That's exactly the reason why interest in cvsserver is always fleeting
-- people hack on it during their team's transition. Perhaps you can
get some help from an Eclipse-wielding member of your team ;-)

> 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

That would be good, and is not too hard. You can mostly simulate that
extending the sqlite DB.

With that in place, a _very_ cool thing would be to add a special
"initial run" script, intended for projects that have just been
imported from a real CVS repo. The initial run script would look at
the CVS repo and add the needed version skew to make the revision
numbers of each file in sqlite match the cvs repo. For sane imports
this would work pretty well, and there's an amount of safe "skew" you
can add for slightly not-sane imports.

The end result is that a project can switch from CVS to git +
git-cvsserver and end users would not need to change their CVS
checkouts at all. Covert cvs->git migration, and users switch to git
on their own schedule.

WRT to your other notes, I agree that cvs update -j -j support isn't
interesting -- users that do merge will want to be on the git side of
things -- but it isn't hard. Submodules is probable not worth the
hassle - at least not yet :-) and a nested CVS checkout works
transparently - in some cases moreso than git submodules!

cheers,



m
-- 
 martin.langhoff@gmail.com
 martin@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff