diff --git a/doc/작업지시/5차.md b/doc/작업지시/5차.md new file mode 100644 index 0000000..df94125 --- /dev/null +++ b/doc/작업지시/5차.md @@ -0,0 +1,124 @@ +# 작업 지시 — MergeHub 5차 (실제 소스에 맞추기) + +대상: `D:\Sorce\MergeTool\MergeHub` (플러그인) · `D:\Sorce\MergeTool\UbisamPlatform` (셸) +전제: 1~4차 지시서는 모두 끝났다([../진행상황.md](../진행상황.md)). + +**이번 지시서가 앞과 다른 점** — 지금까지는 시험용 파일로만 확인했다. +5차는 **실제 소스(`D:\Sorce\LGE-OC6-Inline-CylinderTypeWelder`)를 재 보고 나온 것**들이다. +아래 숫자는 2026-09-10 에 실제로 센 값이다. + +| 잰 것 | 값 | +|---|---| +| 소스 파일 | 2,115개 · 426,723줄 | +| 갈래 | **C# 1,691개(382,176줄) · XAML 400개(42,477줄)** · .h 24개 | +| 가장 큰 파일 | `RTC6Wrap.cs` 7,479줄 (428KB) | +| BOM 없는 한글 파일 | 420개 — 그중 **CP949 가 67개** | +| 폴더 비교(4,503개) | **12.2초** | +| 7,479줄에서 편집 | 글자 31ms · 엔터 31ms · 재정렬 222ms (문제 없음) | + +--- + +## 공통 규칙 + +- **A → B → C 순서로 진행한다.** A 는 잘못 되면 남의 소스를 망가뜨리는 문제라 제일 먼저다. +- **항목 하나를 끝낼 때마다** 빌드하고 실제로 실행해 화면을 확인한 뒤 보고한다. +- **항목 하나가 끝나면 기록을 세 군데에 남기고 로컬 커밋한다**(4차 D-2 에서 정한 규칙). + 1. **상세**는 `doc/history/YYYY-MM-DD-주제.md` — 원인 · 판단 · 확인한 결과 + 2. [../진행상황.md](../진행상황.md) 은 **대기 → 완료로 상태만** + 3. [../history/changelog.md](../history/changelog.md) 에 한 줄 — 날짜 · 무엇을 왜 · 커밋 +- **푸쉬하지 않는다.** +- **실제 저장소(`LGE-OC6-...`)를 고치지 않는다.** 읽기만 한다. 시험이 필요하면 사본을 뜬다. + 이건 남의 작업물이고, 우리 도구가 망가뜨리면 되돌릴 방법이 없다. +- 기존 검사 하네스 17벌(571건)은 계속 통과해야 한다. 로직을 건드리면 **테스트를 먼저 늘린다.** +- 빌드 경고 0 · 오류 0 을 유지한다. 앱이 실행 중이면 `UbisamBase.Shell` 을 먼저 종료한다. +- 플랫폼을 고치면 다른 소비 프로그램에 미치는 영향을 함께 적고 + `UbisamPlatform/doc/history/changelog.md` 에 남긴다. + +--- + +## A. 남의 소스를 망가뜨릴 수 있는 것 + +### A-1. CP949 파일 67개를 잘못 읽으면 한글이 깨진다 + +- 실제 소스에 **BOM 없는 한글 파일이 420개**, 그중 **67개가 CP949** 다(예: `AXA.cs`). + 나머지 353개는 BOM 없는 UTF-8 이다. **한 저장소 안에 두 인코딩이 섞여 있다.** +- `TextFile.Detect` 가 이 판단을 하고 있는데, **실제 파일로 맞는지 확인한 적이 없다.** + 잘못 읽으면 화면에서 한글이 깨져 보이고, 그대로 저장하면 **파일이 실제로 망가진다.** +- **먼저 확인만 한다.** 67개 CP949 파일과 353개 UTF-8 파일을 전부 열어(또는 `TextFile.Read` 로 훑어) + 한글이 제대로 읽히는지 세어 보고 **숫자로 보고한다.** 틀리는 파일이 있으면 그 다음에 고친다. +- 저장 쪽도 본다. `저장 형식 = 원본 유지` 가 CP949 파일을 **CP949 로 되돌려 쓰는지** 확인한다. + 사본으로 시험하고 **바이트 단위로 견준다** - 눈으로 보면 모른다. +- **판정 기준**: CP949 67개 · UTF-8 353개를 열어 한글이 깨지는 파일이 **0개**다. + 사본을 열어 한 글자도 고치지 않고 저장했을 때 **바이트가 그대로**다. + +### A-2. 커밋·체크아웃 뒤에 저장 안 한 편집이 조용히 사라진다 + +- 4차 A-1 에서 여덟 군데를 막았지만 **`RefreshCommits` → `LoadCommitAsync` 는 일부러 두었다.** + 프로그램이 목록을 다시 세우는 자리라 그 한가운데 확인 창을 띄우면 무엇에 답하는지 알 수 없고, + 취소해도 목록은 이미 새로 세워진 뒤라 되돌릴 자리가 없기 때문이다. +- 남은 구멍인 것은 맞다. Git 탭에서 커밋·체크아웃·pull 을 하면 고치던 내용이 다시 읽힌다. +- **막는 자리를 바꿔서 푼다.** 목록을 다시 세우는 자리가 아니라 **Git 작업을 시작하는 자리**에서 묻는다. + 그 순간에는 아직 아무것도 바뀌지 않았으므로 취소가 뜻이 있다. +- **판정 기준**: LOCAL 을 고친 채 Git 탭에서 커밋·체크아웃을 누르면 묻는다. + 취소하면 Git 작업도 일어나지 않고 편집도 그대로다. + +--- + +## B. 실제 소스에 맞추기 + +### B-1. XAML 색칠이 사실상 없다 + +- 실제 소스에 **XAML 이 400개 · 42,477줄**이다. C# 다음으로 많다. + 그런데 지금 XAML 은 주석과 따옴표만 알아본다(`LanguageProfile.Markup`). + **태그 이름 · 속성 이름 · 속성 값이 전부 같은 색**이라 사실상 평문이다. +- 3차 D-2 에서 C++ 전처리 지시문을 넣었는데, **정작 실제 소스에는 .h 가 24개뿐**이었다. + 힘을 쓴 자리가 어긋나 있었다. +- 태그 이름 · 속성 이름 · 속성 값 · 주석 네 가지만 갈라도 읽기가 크게 달라진다. + 마크업은 단어 단위가 아니라 꺾쇠 안인지 밖인지로 갈리므로 지금 토크나이저에 그대로 얹기 어렵다. + 얹을 수 있는지부터 보고, 아니면 마크업용 갈래를 따로 둔다. +- **판정 기준**: 실제 XAML 파일(예: `UCManual*.xaml`)을 열었을 때 태그와 속성이 눈으로 갈린다. + C# 파일의 색칠은 달라지지 않는다. + +### B-2. 폴더 비교가 실제 저장소에서 12초 걸린다 + +- 4,503개를 견주는 데 **12.2초**다. 멈춘 것처럼 보이지는 않지만(취소도 되고 진행도 보인다) 길다. +- **먼저 무엇이 오래 걸리는지 재고 보고한다.** 폴더를 훑는 시간인지, 파일을 여는 시간인지, + 화면에 트리를 세우는 시간인지. 재지 않고 고치면 엉뚱한 데를 고친다. +- 줄일 수 있는 자리를 찾아 고친다. 크기·수정 시각이 같으면 내용을 안 여는 길은 이미 있다(빠른 비교). + **기본 동작을 바꾸지는 않는다** - 빠른 비교는 틀릴 수 있어 사용자가 고르는 것으로 남긴다. +- **판정 기준**: 같은 저장소를 다시 비교했을 때 **눈에 띄게 빨라진다.** + 결과(전체·다름·한쪽만 개수)는 고치기 전과 똑같다. + +--- + +## C. 실전 투입 + +### C-1. 실제 저장소로 병합을 한 번 끝까지 해 본다 + +- 지금까지 3-Way 병합은 **데모 저장소로만** 확인했다. 실제 소스로 해 본 적이 없다. +- **사본을 떠서** 한다(`LGE-OC6-...` 원본은 건드리지 않는다). + 브랜치 두 개를 만들어 같은 파일을 양쪽에서 고치고, 병합 → 충돌 → MergeHub 로 해결 → 커밋까지 간다. +- **고치지 말고 먼저 적는다.** 걸린 것 · 헷갈린 것 · 느린 것을 그대로 적어 보고한다. + 그 목록이 6차 지시서가 된다. +- **판정 기준**: 사본 저장소에서 충돌 하나를 MergeHub 만으로 해결해 커밋까지 끝낸다. + 그 과정에서 나온 문제를 목록으로 남긴다. + +--- + +## 이번 지시서에서 하지 않는 것 + +- **대용량 파일 성능** — 잴 필요가 없어졌다. 실제 소스의 가장 큰 파일이 **7,479줄**이고, + 거기서 글자 31ms · 엔터 31ms · 전체 재정렬 222ms 로 다 빠르다. 미룬 것 목록에서 뺀다. +- 같은 줄 접기(4차 B-2) · 외부 편집기(4차 B-4) — 미룬 그대로 둔다. +- 로그인·권한 — 로컬 도구가 우선이다. + +--- + +## 보고 형식 + +항목마다 이렇게 적는다. + +- 무엇이 원인이었는지 한두 줄 (재 보는 항목이면 잰 값) +- 어떤 파일을 어떻게 고쳤는지 +- 실제로 실행해 확인한 결과 +- 커밋 해시 \ No newline at end of file diff --git a/doc/진행상황.md b/doc/진행상황.md index 219c1dc..18f3100 100644 --- a/doc/진행상황.md +++ b/doc/진행상황.md @@ -53,12 +53,39 @@ --- +## 5차 — 실제 소스에 맞추기 (2026-09-10 ~) + +지시서: [작업지시/5차.md](작업지시/5차.md). 지금까지는 시험용 파일로만 확인했다. +5차는 실제 소스(`LGE-OC6-Inline-CylinderTypeWelder` · 2,115개 · 426,723줄)를 재 보고 나온 것들이다. + +### A. 남의 소스를 망가뜨릴 수 있는 것 + +| 상태 | 항목 | +|---|---| +| 대기 | A-1 CP949 파일 67개를 잘못 읽으면 한글이 깨진다 | +| 대기 | A-2 커밋·체크아웃 뒤에 저장 안 한 편집이 조용히 사라진다 | + +### B. 실제 소스에 맞추기 + +| 상태 | 항목 | +|---|---| +| 대기 | B-1 XAML 색칠이 사실상 없다 (400개 · 42,477줄) | +| 대기 | B-2 폴더 비교가 실제 저장소에서 12초 걸린다 | + +### C. 실전 투입 + +| 상태 | 항목 | +|---|---| +| 대기 | C-1 실제 저장소로 병합을 한 번 끝까지 해 본다 | + +--- + ## 3~4주차로 미룬 것 디테일이라 지금 붙잡을 일이 아니다. - 로그인·권한 -- 대용량 파일 성능 (수만 줄) — 실제 소스 크기를 확인한 뒤 판단 +- ~~대용량 파일 성능~~ — 잴 필요가 없어졌다(2026-09-10). 실제 소스의 가장 큰 파일이 7,479줄이고 편집·이동·재정렬이 모두 빠르다 - 같은 줄 접기 (4차 B-2) — 차이 이동만으로 부족하다고 느끼는 순간이 오면 그때 - 외부 편집기로 열기 (4차 B-4) — 설정 값 두 개를 채우는 수고가 얻는 것보다 컸다