80 년대와 90 년대의 마이크로 컴퓨터에서 버전 관리는 어떻게 작동 했습니까?

프로그래머 팀이 일반적으로 80 년대와 90 년대 초반에 소프트웨어 개발을 어떻게 관리했는지 알고 싶습니다. 모든 소스 코드가 모든 사람이 작업하는 하나의 컴퓨터에 단순히 저장되었거나 소스가 플로피를 통해 수동으로 복사 및 복사되어 수동으로 병합되었거나 실제로 우리가하는 것처럼 네트워크 (예 : CVS)를 통해 수정 제어 시스템을 사용 했습니까? 지금? 아니면 오프라인 CVS와 같은 것이 사용 되었습니까?

오늘날 모든 사람들은 소스 제어에 의존하고 있습니다. 그러나 80 년대에 컴퓨터 네트워크는 설정하기가 쉽지 않았으며 모범 사례와 같은 것들이 여전히 밝혀졌습니다 ...

70 년대와 60 년대 프로그래밍은 상당히 다르므로 개정 제어가 필요하지 않다는 것을 알고 있습니다. 그러나 80 년대와 90 년대에 사람들이 코드를 작성하기 위해 컴퓨터를 사용하기 시작했고 응용 프로그램의 크기와 범위가 커지기 시작했기 때문에 사람들이 그 모든 것을 어떻게 관리했는지 궁금합니다.

또한 플랫폼마다 어떻게 다른가요? Apple vs Commodore 64 vs Amiga vs MS-DOS vs Windows vs Atari

참고 : 저는 주로 대형 UNIX 시스템이 아니라 오늘날 마이크로 컴퓨터 에서의 프로그래밍에 대해 이야기하고 있습니다.

첫째, 마이크로 컴퓨터가 처음 나왔을 때 소프트웨어는 대부분 Unix 또는 VMS 시스템에 작성되었고 대상 시스템에 "교차 컴파일러 / 조립"되었습니다. 이 컴퓨터 시스템은 종종 많은 터미널을 가진 다중 사용자였으며 SCCS 와 같은 소스 코드 제어 시스템을 가졌습니다 .

네트워킹은 1980 년대 중반부터 마이크로 컴퓨터의 옵션으로, 종종 "파일 서버"로 Unix 시스템에 연결되었습니다 (UNIX 시스템의 SCCS를 사용하여 RS232 및 Kermit을 사용하여 파일을 전송할 수 있음)

몇 년 동안 버전 제어 시스템이 어떻게 변경되었는지에 대한 개요를 보려면 Eric Sink 의 버전 제어 기록을 참조하십시오 .

필자는 1980 년대 후반 "BYTE"에서 소스 코드 제어에 대한 기사를 읽었으므로 그때까지 "소형 시스템"에서 사용되고 있었을 것입니다.

SourceSafe 는 Dos, Windows 등에서 실행되는 90 년대 중반에 설립되었습니다.

이 링크는 1994 년부터 PC에서 실행되는 PVCS에 대한 기사를 보여줍니다. 버전 6.2이므로 한동안 분명히 존재 해 왔으며 Wikipedia는 1985 년부터 시작했다고 말합니다 .

그러나 번호가 매겨진 플로피 디스크는 1990 년대 후반까지 소규모 소프트웨어를 사용하는 대부분의 프로그래머가 하드 디스크의 폴더로 교체하여 매일 소스 코드를 복사하여 사용했습니다.

Unit에서 Windows NT 3.5 로의 프로젝트 포팅 소프트웨어 작업을 기억합니다. Windows 용 프로그래밍 방법을 알고있는 프로그래머는 당시에는 소스 코드 제어에 대해 들어 보지 못한 경우가 많았습니다.

이 타임 라인은 codicesoftware 의 블로그 게시물에서 가져 왔으며 Plastic SCM을 판매하지만 다른 시스템의 역사에 대한 개요는 합리적입니다.

이것은 아마도 게임 산업을 대표하지는 않지만 소규모 게임 회사에서 잘 작동했습니다. 다른 요구 사항이있을 수있는 비즈니스 소프트웨어로는 작업하지 않았습니다.

80 년대 중반부터 90 년대 중반까지 파일 이름 끝에 "game.003"과 같은 버전 번호를 자주 사용했습니다. 당시에는 어셈블러에서 90 %를 프로그래밍하고 모든 코드가 하나의 거대한 파일에 있었으며 아마도 하나 또는 두 개의 포함 파일이있었습니다. 여기서 변경 사항에 따라 버전 번호를 수동으로 업데이트해야했습니다. 안정적인 버전을 유지 한 후에 만 ​​숫자를 늘릴 것입니다.

이것은 결국 약 3 명으로 다소 편안하게 확장되었습니다. 그 후 우리는 팀을 키우고 1 년 동안 파일을 엉망으로 만들었습니다. 개별 사람들의 변경 사항을 추적하려고 노력할 때까지 1997-98 년경에 Perforce를 사용하기 시작했습니다.

당시의 일반적인 인프라 스트럭처에서이를 확인해야합니다. 80 년대 초 IBM은 "개인용 컴퓨터"를 출시했으며이를 문자 그대로 받아 들일 수 있습니다. PC 용 응용 프로그램을 개발하는 가장 일반적인 방법은 무언가를 만들어 팔려고하는 사람이었습니다. 따라서 릴리스 된 버전 당 하나의 플로피가 일반적 일 것입니다. 멋진 화려한 라벨을 사서 제품 이름과 버전을 쓸 수 있습니다. 그 당시의 성공적인 제품의 대부분은 그것을 쓴 사람의 이름을 알고있었습니다.

네트워크는 애드온으로 소개되었습니다. 클라이언트 API는 DOS에 해킹되었으며 서버 부분은 별도의 시스템에있는 전용 독점 운영 체제였습니다. 일반적으로 비용이 많이 들고 (대중은 아님) 기본적으로 파일 및 프린터 공유 만 제공합니다. PC 세계에서는 Windows for Workgroups 및 Windows NT의 도입으로 상황이 바뀌기 시작했습니다. 그것은 많은 가능성을 열어주었습니다. 네트워킹은 프로그래머가 익숙한 환경에 통합되었으며 Windows 프로그래머는 네트워크를 통해 서로 통신 할 수있는 응용 프로그램을 작성할 수 있습니다. 이것은 지배적 인 네트워크 운영 체제로서 NetWare의 끝이었습니다.

곧 여러 버전의 제어 시스템이 클라이언트 및 서버 구성 요소와 함께 팝업되어 모든 기계 조합에 쉽게 설치할 수 있습니다. 빌드 시스템에서의 통합을 가능하게하는 명령 행 옵션을 지원하는 IDE 및 클라이언트 컴포넌트 용 플러그인이 있습니다.

웹이 시작되고 인터넷에 대한 PC 액세스가 유비쿼터스가 된 후에는 오픈 소스 이동 및 웹 기반 소스 제어 시스템을 갖게되었습니다. 재미있는 점은 PC가 출시되었을 때 중앙 집중식 컴퓨팅에서 분산 컴퓨팅으로 대담한 움직임으로 보였습니다. 그러나 중앙 대 분산에 대한 정의가 흐려졌습니다. 클라우드는 궁극적 인 배포입니까, 아니면 IBM 메인 프레임과 마찬가지로 모든 기능을 보유한 새로운 괴물 중앙 컴퓨터입니까?

90 년대에는 버전 관리를 위해 소프트웨어를 사용했습니다. SCCS가 있었고 Apple의 MPW에는 내장 버전 관리 (프로젝터)가있었습니다. 한 회사에서 버전 관리 시스템은 일주일에 한 번 찍은 모든 버전의 플로피 디스크가있는 대형 찬장이었습니다.

학교에 다니는 동안의 첫 번째 여름 프로그래밍 작업은 (제 생각에 91 년경이었을 것입니다.) 제가 일하는 소규모 회사를위한 자동 버전 관리 및 백업 시스템을 구현하는 것이 었습니다. 우리는 3 대의 PC가 네트웨어 서버에 연결되어 있었고, 소유자는 마침내 버전 충돌을 처리하고 플로피에 백업해야하는 작업을 수행하는 데 지쳤습니다. 그들은 지금까지 가지고 있었고, 아무도 파일을 사용하지 않았는지 확인한 프로그램을 실행할 때까지만 모든 파일을 읽도록 설정된 시스템을 작성하고 중앙 쿼리 데이터베이스 (단순 쿼리가있는 관계형 데이터베이스)에 사용을 기록했습니다. netware 서버에서 실행되는 전체 SQL 대신 api). 다른 프로그램이 수정 된 변경 사항을 체크 아웃하여 서버에 복사했습니다.

이 시스템은 내가 일했던 소규모 회사를 위해 맞춤 제작되었지만 많은 유사한 상점들이 비슷한 프로세스를 가지고 있다고 생각합니다.

개인적인 경험으로부터 : 1985 MS-DOS 네트워크 개발 PVCS가 이용 가능하고 너무 비쌌습니다. Apple 및 모든 비 MSDOS PC의 경우 : 아무것도 없습니다. 저는 1987 년부터 T-lib ($ 50)를 사용했습니다. Unix 포트 (SCCS)는 1990 년경부터 필터링을 시작했고 1992 년경 SourceSafe에서는 필터링을 시작했습니다.

1995 년까지 VCS를 사용하지 않았다면 심각하지 않았습니다.

1993-1995 년에는 SPARCOS 20 및 Sun IPX를 사용하여 SunOS에서 C / C ++ 개발을 수행하는 15 명의 개발자가있는 연금 관리자와 함께있었습니다. 우리의 코드베이스는 NFS 마운트 디렉토리에있었습니다. 처음에는 Copy Folder Versioning 을 수행하고 있었지만 어느 시점에서 SCCS 로 옮겼 으며 일부 팀은 RCS를 사용하기 시작했습니다 .

1995 년 뉴욕, 런던, 홍콩에서 C / C ++ 개발을하는 80 명 이상의 개발자와 함께 다른 회사로 이사했습니다. 우리 는 개발 환경을 관리하기 위해 다중 사이트 애드온과 함께 ClearCase 를 사용했습니다 .

ClearCase는 사이트간에 코드베이스를 동기화하는 데 능숙했지만 당시에는 거의 풀 타임 관리자가 작업을 계속 수행해야했습니다. ClearCase는 가상 파일 시스템에 파일을 표시하고 분기, 시간 및 / 또는 태그를 기반으로 디렉토리 버전 및 와일드 카드 파일 이름을 지정하는 구성을 제공하므로 속도가 훨씬 느려졌습니다. 병리학 적 사례에서는 모든 개별 파일이 다른 버전을 갖도록 지정할 수 있습니다.