ksj09406
9c0106be57
여기는 머지툴을 만드는 자리다. 남의 저장소를 읽을 까닭이 더 남아 있지 않고, 읽는 동안 사고가 날 여지만 있다. 이미 받아 둔 숫자 (XAML 400개, CP949 67개, 4,503개에 12.2초)는 그대로 쓴다. B-2 와 C-1 을 그에 맞게 다시 썼다. 둘 다 큰 재료가 필요한데, 이제 우리가 만들어 쓴다. 만든 묶음은 몇 번을 돌려도 같은 값이 나와서 재기에는 오히려 낫다. C-1 에는 그 한계도 같이 적었다 - 만든 소스에는 진짜 코드의 지저분함이 없다. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
138 lines
8.9 KiB
Markdown
138 lines
8.9 KiB
Markdown
# 작업 지시 — MergeHub 5차 (실제 소스에 맞추기)
|
|
|
|
대상: `D:\Sorce\MergeTool\MergeHub` (플러그인) · `D:\Sorce\MergeTool\UbisamPlatform` (셸)
|
|
전제: 1~4차 지시서는 모두 끝났다([../진행상황.md](../진행상황.md)).
|
|
|
|
**이번 지시서가 앞과 다른 점** — 지금까지는 시험용 파일로만 확인했다.
|
|
5차는 **실제 소스를 한 번 재 보고 나온 것**들이다.
|
|
아래 숫자는 2026-09-10 에 실제로 센 값이다. 그 값은 그대로 둔다.
|
|
|
|
> **2026-09-11 부터 실제 소스를 더 보지 않는다.** 여기는 머지툴을 만드는 자리다.
|
|
> 남의 저장소를 읽을 까닭이 남아 있지 않고, 읽는 동안 사고가 날 여지만 있다.
|
|
> 재료가 필요하면 **우리가 만든 시험용 묶음**을 쓴다.
|
|
> 그래야 같은 시험을 몇 번이고 똑같이 돌릴 수 있어 오히려 재기에 낫다.
|
|
|
|
| 잰 것 | 값 |
|
|
|---|---|
|
|
| 소스 파일 | 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) 에 한 줄 — 날짜 · 무엇을 왜 · 커밋
|
|
- **푸쉬하지 않는다.**
|
|
- **실제 소스를 열지 않는다.** 고치지 않는 것은 물론이고 읽지도 않는다(2026-09-11 결정).
|
|
시험 재료는 **우리가 만들어 쓴다.** 남의 작업물이고, 우리 도구가 망가뜨리면 되돌릴 방법이 없다.
|
|
이미 받아 둔 숫자는 그대로 쓴다 - 다시 재려고 남의 폴더를 열 일이 아니다.
|
|
- 기존 검사 하네스 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개뿐**이었다.
|
|
힘을 쓴 자리가 어긋나 있었다.
|
|
- 태그 이름 · 속성 이름 · 속성 값 · 주석 네 가지만 갈라도 읽기가 크게 달라진다.
|
|
마크업은 단어 단위가 아니라 <b>꺾쇠 안인지 밖인지</b>로 갈리므로 지금 토크나이저에 그대로 얹기 어렵다.
|
|
얹을 수 있는지부터 보고, 아니면 마크업용 갈래를 따로 둔다.
|
|
- **판정 기준**: 실제 XAML 파일(예: `UCManual*.xaml`)을 열었을 때 태그와 속성이 눈으로 갈린다.
|
|
C# 파일의 색칠은 달라지지 않는다.
|
|
|
|
### B-2. 폴더 비교가 큰 저장소에서 12초 걸린다
|
|
|
|
- 4,503개를 견주는 데 **12.2초**다(2026-09-10 실제 소스에서 잰 값). 멈춘 것처럼 보이지는 않지만
|
|
(취소도 되고 진행도 보인다) 길다.
|
|
- **재는 데 쓸 폴더는 우리가 만든다.** 실제 소스는 더 열지 않는다.
|
|
깊이·파일 수·크기 분포를 비슷하게 맞춘 묶음을 한 번 만들어 두고 그것으로 고치기 전후를 견준다.
|
|
만든 묶음이라 **몇 번을 돌려도 같은 값**이 나온다 - 오히려 재기에 낫다.
|
|
- **먼저 무엇이 오래 걸리는지 재고 보고한다.** 폴더를 훑는 시간인지, 파일을 여는 시간인지,
|
|
화면에 트리를 세우는 시간인지. 재지 않고 고치면 엉뚱한 데를 고친다.
|
|
- 줄일 수 있는 자리를 찾아 고친다. 크기·수정 시각이 같으면 내용을 안 여는 길은 이미 있다(빠른 비교).
|
|
**기본 동작을 바꾸지는 않는다** - 빠른 비교는 틀릴 수 있어 사용자가 고르는 것으로 남긴다.
|
|
- **판정 기준**: 같은 저장소를 다시 비교했을 때 **눈에 띄게 빨라진다.**
|
|
결과(전체·다름·한쪽만 개수)는 고치기 전과 똑같다.
|
|
|
|
---
|
|
|
|
## C. 실전 투입
|
|
|
|
### C-1. 병합을 한 번 끝까지 해 본다
|
|
|
|
- 지금까지 3-Way 병합은 **데모 저장소로만** 확인했다. 데모는 파일이 다섯 개다.
|
|
<b>한 번도 "긴 파일 여러 개에서 충돌이 여기저기 난" 상황을 겪어 본 적이 없다.</b>
|
|
- **저장소는 우리가 만든다.** 실제 소스는 열지 않는다.
|
|
데모보다 훨씬 크게 - 파일 수백 개, 그중 몇 개는 수천 줄, C# 과 XAML 을 섞어서 - 만들어 두고
|
|
브랜치 두 개에서 같은 파일을 양쪽에서 고친 뒤, 병합 → 충돌 → MergeHub 로 해결 → 커밋까지 간다.
|
|
- **이 방법의 한계를 알고 한다.** 만든 소스는 진짜 코드의 지저분함이 없다.
|
|
여기서 안 걸렸다고 실제에서 안 걸린다는 뜻은 아니다. 그래도 데모 다섯 파일보다는 훨씬 낫다.
|
|
- **고치지 말고 먼저 적는다.** 걸린 것 · 헷갈린 것 · 느린 것을 그대로 적어 보고한다.
|
|
그 목록이 6차 지시서가 된다.
|
|
- **판정 기준**: 만든 저장소에서 충돌 하나를 MergeHub 만으로 해결해 커밋까지 끝낸다.
|
|
그 과정에서 나온 문제를 목록으로 남긴다.
|
|
|
|
---
|
|
|
|
## 이번 지시서에서 하지 않는 것
|
|
|
|
- **대용량 파일 성능** — 잴 필요가 없어졌다. 실제 소스의 가장 큰 파일이 **7,479줄**이고,
|
|
거기서 글자 31ms · 엔터 31ms · 전체 재정렬 222ms 로 다 빠르다. 미룬 것 목록에서 뺀다.
|
|
- 같은 줄 접기(4차 B-2) · 외부 편집기(4차 B-4) — 미룬 그대로 둔다.
|
|
- 로그인·권한 — 로컬 도구가 우선이다.
|
|
|
|
---
|
|
|
|
## 보고 형식
|
|
|
|
항목마다 이렇게 적는다.
|
|
|
|
- 무엇이 원인이었는지 한두 줄 (재 보는 항목이면 잰 값)
|
|
- 어떤 파일을 어떻게 고쳤는지
|
|
- 실제로 실행해 확인한 결과
|
|
- 커밋 해시 |