Re: [PATCH 0/3] git-cvsserver: Add support for some binary files
- From
Martin Langhoff <martin.langhoff@gmail.com>
- Date
- May 19, 2008, 10:53 UTC
- Message-ID
- <46a038f90805190353o42fe59f2lfee9b6befdd588db@mail.gmail.com>
- In-Reply-To
- <20080519073535.GA2885@comcast.net>
On Mon, May 19, 2008 at 7:35 PM, Matthew Ogilvie <mmogilvi_git@miniinfo.net> wrote:
Show 5 quoted lines
> 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