Subject: Re: Qgit performance and maintain CVS environment with GIT repository

From: Pete/Piet Delaney <[email-masked]>
Date: Thu, 18 Oct 2007 16:41:52 -0700

Marco Costalba wrote:
> On 10/17/07, Robin Rosenberg <[email-masked]> wrote:
>> You could avoid the temporary files if you just pipe the diff to kompare. That
>> would require an option to tell qgit that the external viewer can read a git diff.
>>
>> At the time qgit 1.5 was written, kompare could not handle git diffs.
>>
> 
> So does the other tools I have checked at that time.
> 
> But I don't know if this fixes the problem of slowness reported. A
> little test Pete may do is just as I have written in the former email:
> try to save the big files that cause troubles where he prefers and run
> Kompare on them directly from the command line.
> 
> Is kompare faster? If no probably the 'pipe' technique will not solve
> the problem and shrinks the applicability of the external diff
> launcher to tools that handle diffs directly.

Marco:
   I'll try kcompare on the huge files both on and off the NFS
   file system to see if it has a noticeable impact.

Johannes:
  I read somewhere in the past week that it was possible to maintain
  our existing CVS environment with git. I though it was a separate
  package to export git back to cvs but I just noticed a git-cvsserver
  and as a std part of git and was wondering about using that.

  We have a number of build machines with flamebox perl scripts pulling
  out CVS branches for builds. I was wondering what is the best way to
  use git and it's nicer pull/push model and merge facility and possibly
  maintain CVS exports for scripts doing builds if possible the cvsweb
  and bonsai (CVS Query Form) that a number of engineers are currently
  using. I started looking over out flamebox scripts with the intent
  up converting them over to git but I mentioned the git to cvs
  coexistence and we are wondering if that's a better route than
  upgrading the flamebox scripts. Having our existing cvsweb, bonsai,
  and gitweb along with the git utilities seems at least desirable.
  Any thoughts or suggestions?

- -piet

> Marco