2012-04-21 3 views
6

상당히 크고 복잡한 자바 프로젝트 (백만 줄 이상)와 10 년 동안의 역사에 대해 EGit을 사용하고 있습니다.
여기 나는 EGit에서 심각한 성능 문제에 직면하고있다. Java 파일에서 한 줄의 작은 변화만으로도 EGit은 전체 시스템 속도를 늦추는 몇 분 동안 색인을 다시 생성하게된다. 실제로 "자식 상태"명령 줄에서 약 1 분 정도 걸리므로 자식 명령 줄이 조금 느립니다. 그러나이 성능 문제로 인해 & EGit 커밋 대화 상자 속도 저하 문제 (link)가 발생할 수 있습니다. 커밋 및 업데이트를 위해 git 명령 줄을 사용할 수 있기 때문에 생산성에 영향을 미치기 때문에 이클립스 성능을 트레이드 오프하고 싶지는 않습니다.Eclipse에서 EGit 최적화에 대한 제안

  1. 추가 모든 클래스 폴더를 제외 파일 :

    다음

    제가 인터넷 검색을하고 주위 사람들에게 물어 시도 것입니다. 실제로 시간이되는 동안 클래스 folderin. gitignore 퍼팅 시도했다.
  2. 기계를 하루 동안 켜둔 채로 색인 생성을 마칠 수있을만큼 충분한 시간을줍니다.
  3. Git staging, history 및 기타 모든 일식보기는 개발 중에 Eclipse 작업 영역에서 닫힙니다.
  4. "git gc"- 명령 행 성능에는 차이가 있지만 EGit에는 차이가 거의 없습니다.
  5. Git 용 Checked Label Decorator. 환경 설정 -> 일반 -> 모양 -> 레이블 꾸미기.
  6. JGit이 경로 변환을 위해 cygwin을 사용하고있을 가능성이있는 포럼의 어딘가에서 읽은 경로에서 cygwin을 삭제했습니다.
  7. 이클립스에서 윈도우 캐시가 10에서 70m로 증가했습니다 (환경 설정 -> 팀 -> 힘내 -> 윈도우 캐시).

추 신 : 저장소 저장소가 svn 원격 저장소를 가리 킵니다. 또한, 나는 초보자이기 때문에 설치에 실수를했을 수도 있으므로 아무 것도 지적 해 주시기 바랍니다.

여기 내 시스템 정보입니다. 멋진 하드웨어 사양이 없지만 여분의 RAM (8GB)이 필요합니다.

  • 자식 - GUI 버전 0.16 GITGUID
  • 자식 버전 : 1.7.10.mysysgit.1
  • JDK 1.6_025
  • 이클립스 버전 : 매개 변수 3.7.2 자바 EE 버전 -Xms1536m -Xmx1536m
  • EGit : 1.3.0.201202151440
  • 윈도우 7 프로세서 :는 IS 코어 2 듀오 2.6GHz의

답변

0

CVCS (집중식 VCS)와 DVCS (분산 형) 사이의 문제 :

  • 하나의 SVN 저장소에는 GB 상당의 데이터가 포함될 수 있습니다.
  • Git repo는 작게 유지해야하며 복수의 Git repos를 통해 submodules을 활용해야합니다.

많은 repos가 거대한 Git repo보다 성능이 좋을 것으로 생각됩니다. 그렇지 않으면 bug 323839처럼 동기화 문제가 발생하기 시작합니다.

하지만 Git repos와 SVN 저장소간에 SVN 작업 공간을 통해 복사하거나 Git repos new evolutions를 복사중인 SVN 작업 공간을 통해 수동으로 (단순화 된) 동기화를 관리하는 것을 의미합니다. SVN workspace in commit.

+1

VonC - 동의하지만, 리눅스 커널 파일 시스템이 훨씬 빠르다고 동의하지만, 같은 큰 git repo가 ​​IntelliJ로 리눅스 박스에서 꽤 잘 수행하기 때문에 Egit 구현에는 약간의 문제가 있습니다. 그래서, SVN의 클론 인 하나의 중앙 힘내 저장소를 만들고 거대한 중앙 자식보고에서 여러 개의 작은 자식 서버를 가질 수 있습니까? – Hemant

+0

@Hemant 아니오, 당신은 할 수 없습니다 (SVN repo에 커밋 할 가능성은 없습니다). 모든 작은 것들을 서브 모듈로 선언하는 하나의 Git repo를 정의 할 수 있지만 SVN repo와의 링크는 없습니다. 따라서 수동 동기화 메커니즘이 남습니다. – VonC

+0

폰 - 명확히 해 주셔서 감사합니다. 내 옵션을 계속 탐험 할게 ... Egit 팀이 성능 튜닝을 더 빨리하기를 바랍니다. – Hemant

3

이것은 아마도 당신의 문제는 아니지만이 페이지는 egit 성능과 관련하여 google에 올라온 것입니다. 일단 성능 문제의 원인이 untracked (indexed?) 파일입니다. 로컬 디렉토리 트리에 많은 수의 비 추적 파일이 없는지 확인하십시오. 이는 성능에 심각한 영향을 미치기 때문입니다. 10K + 파일로 디렉터를 삭제하고 커밋 성능이 1 분 이상 걸린 후 커밋 대화 상자를 열어 몇 초가 걸렸습니다.

+0

내 저장소에 추적 할 수없는 파일이 없습니다. 약 28k Java 파일과 136k 커밋을 가진 거대한 저장소에서 작업하고 있지만 대부분은 이미 압축되어 있어야합니다. – Hemant

+0

'git : // git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git' 복제를 시도하십시오. Linux 커널 체크 아웃에는 약 45k 개의 파일이 있고 커널에는 300k 커밋 이상의 방법이 있습니다. 28k 파일과 136k 커밋이 포함 된 레포는 큰 것이 아니라 큰 것입니다. –

+0

거대한 repo를 위해'https : // github.com/mozilla/gecko-dev.git'를 복제 해보십시오. 클론은 1.5GB의 데이터를 유선으로 전송해야합니다. –