端口与体系
742 对应 IANA 登记的 netrcs，登记说明为网络化版本控制系统，登记人 Gordon C Galligher。它出现在版本控制尚未形成统一标准的年代，核心思路是代码库集中存放在服务器上，客户端通过网络访问与提交。
形态变化
今天这项职能由集中式与分布式版本控制系统共同承担。分布式方案连提交记录都保存在本地，离线也能工作，使用形态与当年完全不同，这也是这类老服务端端口逐渐消失的原因。
基本信息
| 服务名称 | netrcs |
|---|---|
| IANA 登记说明 | 网络化版本控制系统 |
| 传输协议 | TCP 与 UDP |
| 登记机构 | Gordon C Galligher |
| 所属体系 | 早期版本控制服务 |
| 当前状态 | 历史注册项 |
典型使用场景
- 老系统盘点：确认是否还有早期版本控制服务在运行
- 形态对照：理解集中式与分布式版本控制的取舍
- 迁移评估：把历史代码库迁到现代平台时梳理仓库与权限
- 扫描报告解读：扫描器标注 netrcs，与实际进程比对
- 遗留放行规则回收：清理历史服务端口的策略条目
- 未知服务处置：无对应组件时按未知服务流程取证
定位占用进程
定位占用进程
# Linux：查看 742 的监听进程
ss -lntup 'sport = :742'
# 交叉验证可执行文件归属
sudo lsof -i :742
# 核对系统上在用的版本控制命令，判断实际形态
# git --version / svn --version
# Windows：取 PID 后反查
netstat -ano | findstr :742版本控制形态对照
| 形态 | 特点 | 现状 |
|---|---|---|
| 早期网络化服务 | 集中存放，依赖服务端访问 | 历史实现 |
| 集中式 | 统一服务端，提交需联网 | 仍在广泛使用 |
| 分布式 | 本地提交，离线可用 | 现代主流 |
迁移代码库时最容易被忽略的是历史与权限：提交历史是否完整保留、分支与标签是否迁移、访问权限如何映射。只搬最新代码，等于丢失了问题追溯能力。
版本控制服务往往承载了构建与发布的依赖。迁移前梳理哪些流水线直接访问服务端地址，能避免切换后构建集中失败这类问题。