Centralized Version Control Systems(1 - 4)

The next major issue that people encounter is that they need to collaborate with developers on other systems. To deal with this problem, Centralized Version Control Systems (CVCSs) were developed. These systems (such as CVS, Subversion, and Perforce) have a single server that contains all the versioned files, and a number of clients that check out files from that central place. For many years, this has been the standard for version control.

 

다음 주요한 이슈 / 사람들이 맞닥뜨리다 / 협력이 필요 할때 / 다른 시스템에서의 개발자들과. / 이문제를 다루기 위해, / CVCS가 개발 되었다. / 이 시스템은 단일 서버를 가지고 있다 / 모든 버전 파일이 포함된, / 그리고 / 다수의 고객 / 검증된 파일? / 중심지로부터. / 여러 해 동안, / 버전 제어의 표준이 되었습니다. 

 

다음 사람들이 접하는 주요 이슈는 그들이 다른 시스템의 개발자들과 협력이 필요할 때이다. 이 문제를 다루기 위해, CVSS가 개발되었다. 이 시스템은 모든 버전 파일들이 포함된 단일 서버, 중심지로부터 파일들을 확인할 수 있는 다수의 고객들을 가지고 있다. 여러 해 동안, 버전 제어의 표준이 되었습니다.

 

This setup offers many advantages, especially over local VCSs. For example, everyone knows to a certain degree what everyone else on the project is doing. Administrators have fine-grained control over who can do what, and it’s far easier to administer a CVCS than it is to deal with local databases on every client.

 

이 구성은 많은 이점을 제공한다, / 특히 로컬 VCS 넘어서 / 예를 들어, / 모두 알고 있다 / 어느 정도 / 다른 모든 사람/ 프로젝트의  / 하고있는 중이다. / 관리자들은 가지고있다 / 세밀한 제어 / ~에 대한 통제 / 누가 무엇을 할수 있다, / 그리고 / ~보다 쉬울 것이다 / 관리하다 / CVCS  /  모든 고객의 로컬 DB를 다루기 위해 / 보다

 

이 장치는 특히 로컬 VCS를 넘어서 많은 이점을 제공한다. 예를 들어, 모든 사람들은 프로젝트의 다른 모든 사람들이 프로젝트에서 무엇을 하는지 어느 정도 알 수 있다. 관리자들은 누가 무엇을 할 수 있는지에 대한 세밀한 통제권을 가지고 있다, 그리고 모든 고객의 로컬 DB를 다루는 것보다 CVCS를 관리하는 것이 더 쉬울 것입니다.

 

 

However, this setup also has some serious downsides. The most obvious is the single point of failure that the centralized server represents. If that server goes down for an hour, then during that hour nobody can collaborate at all or save versioned changes to anything they’re working on. If the hard disk the central database is on becomes corrupted, and proper backups haven’t been kept, you lose absolutely everything — the entire history of the project except whatever single snapshots people happen to have on their local machines. Local VCSs suffer from this same problem — whenever you have the entire history of the project in a single place, you risk losing everything.

 

그러나, 이 장치는 또한 가진다 / 약간의 심각한 불리한 면을. / 가장 명백한건 / 단하나의 실패점 (단일 장애 지점) / 중심이되는 서버 / 나타내다. / 만일 서버가 한 시간동안 다운되면,  / 그 시간동안 / 아무도 할수 없다 / 조금도 협력 / 또는 /  버전 변경 사항 / 헛수고가 되다 / 그들의 노력이. / 만약 하드 디스크가 중심 DB의 하드 디스크가 변질 된다면, / 그리고 / 적절한 백업을 유지하지 못하다, / 모든 것을 잃어버린다 ---- / 전체 히스토리 / 프로젝트 전체 히스토리를 제외한 단일 스냅샷 사용자들 / 그들의 로컬 기계를 가지고있는. / 로컬 VCS는 이러한 문제로 고통 받는다 --- / 언제든지 / 단일 장소 프로젝트에서 전체 히스토리, / 모든것을 잃어버릴 위험을 가지고 있다.

 

그러나, 이 장치는 약간의 심각한 단점을 가진다. 가장 명백한 건 중심 서버에서 나타나는 단일 장애 지점이다. 만약 서버가 한 시간 동안 다운되면, 그 시간 동안 아무도 공동 작업을 할 수 없거나 작업한 버전 변경사항들을 저장할 수 없게 된다.
만약 중앙 DB의 하드디스크가 손상되고, 적절한 백업을 유지하지 못하면, 로컬 컴퓨터에 있는 단일 스냅샷을 제외한 모든 프로젝트 히스토리(기록)가 완전히 손실된다. 로컬 VCS는 이 같은 문제로 골치 아프다.(언제든지 단일 장소(로컬)에 있는 프로젝트의 전체 기록을 잃어버릴 위험성)