아침 내내 무언가를 확인하려고 노력하면서-나는 며칠간의 일을 잃었다는 것을 알게되었습니다.

이전에 발생했으며 SourceSafe에서 흔히 발생합니다. 문제없이 SourceSafe를 성공적으로 사용할 수 있습니까?

내 견해는 간단합니다. 최대한 빨리 다른 것으로 마이그레이션하십시오. 시간이 오래 걸리지 않으며 (WAG 1-2 주) 마이그레이션에 걸리는 시간에 관계없이 관리에 비용을 정당화 할 수 있습니다. 마이그레이션하는 데 약간의 시간이 걸리면 확실한 소스 제어와 소스 코드 손실 가능성이 거의 없습니다. 상사가 회의론자 인 경우 "소스 안전 공포 이야기"또는 이와 유사한 것에 대해 빠른 Google 검색을 수행하십시오.

가장 나쁜. SCM. 이제까지.

SCM에서 잘못된 것은 VSS에서 구현됩니다. StarTeam조차도 Source Safe보다 낫습니다. Source Safe는 버전 제어 세계의 Internet Explorer 1이며 다른 구현으로 대체되었습니다.

어떻게 사용 했습니까?

작업을 완료하기위한 일반적인 워크 플로는

1. 프로젝트를 확인하십시오
2. 모든 파일을 잠그십시오 (지옥의 부정한 문을 연 다른 사람과의 합병을 피하기 위해)
3. 내 일을 했어
4. 매일 내 변경 사항을 확인했습니다.
5. 다시 확인하고 통합 관련 모든 문제를 해결했습니다.
6. 다시 체크인

Subversion과 비교할 때 위의 내용은 웃을 수 있습니다 (빌드를 깨지 않았는지 확인하는 것 제외).

팀의 프로그래밍 관행에 대한 제한

이것이 우리에게 도움이되도록 팀이 지켜야 할 규칙입니다. 귀하의 마일리지가 다를 수 있습니다.

1. 한 사람 만 파일을 편집 할 수 있습니다 (휴일에가는 경우 도움이 됨)
2. 너무 관리하기 어려운 분기하지 마십시오
3. 이전 개정으로 돌아 가지 마십시오

무엇을 할 수 있습니까?

Polarion은 대부분의 기업에서 오픈 소스 버전 관리를위한 사실상의 표준 인 SVN (Source Safe into Subversion)과 같은 도구 를 마이그레이션하는 데 유용한 도구 세트를 제공 합니다. Subversion은 분산 오프라인 팀을 위해 설계된 GIT 또는 Mercurial과 달리 체크인을 허용하기 위해 서버를 사용할 수 있어야합니다.

소스 컨트롤을 SVN / Mercurial / Git으로 변경 하고 뒤돌아 보지 마십시오!

약 1 년 전에 운영을 중단했습니다.

지난 저녁에 체크인 한 내용이 다음날 아침에 없었던 것이 여러 번 발생했습니다. 방금 작업을 마치지 않은 것처럼 보였기 때문에 그 재미를 찾지 못했습니다. 내가 회사에 처음 왔기 때문에 나에게 위험했을 수도 있습니다.

우리는 TFS로 넘어 갔으며 그 이후로 순조롭게 운영되고 있습니다.

내 견해?

사용하기 쉽고, 사용하기에 안전하고, 완전 무료 인 것이 좋습니다. 왜 그것을 전혀 귀찮게 사용합니까?

이것은 우리가 많은 선택을 할 수있는 발전 분야 중 하나입니다. VSS보다 대부분 또는 전부 더 좋습니다.

• 파괴
• 수은제
• 힘내
• 더

상업적 운영에서 SourceSafe를 사용하는 것은 달러 지폐를 태워 건물을 가열하는 것과 같습니다.

2000 년에 8 명의 개발자가 VSS 데이터베이스의 일일 평균 2 회 손상으로 인해 생산성의 5-10 %를 잃었을 수 있습니다. 우리는 매시간 백업을했기 때문에 그 정도는 낮았습니다.

VSS에서 Perforce, svn 및 git으로 이동했기 때문에 SCM 데이터베이스가 손상되지 않았습니다.

나는 이것으로 지옥에 투표 할 수도 있지만 ..

VSS를 사용하면 현재 질식 된 레포가 당신의 잘못이 아니라는 것을 깨닫는 데 필요한 현실을 조정할 수 없을 정도로 효과적으로 마약을 처리 할 수 ​​있습니다.

절대로 사용하지 마십시오.

수년간 그것을 사용했습니다-이미 존재했던 것처럼 기본 솔루션이었습니다. 그것은 몇 번 나에게 물린 적이 있지만 관성은 극복하기가 어렵습니다.

그런 다음 VPN을 통해 원격으로 사용해야했고 심지어 작은 체크인조차도 핀홀을 통해 벽돌을 채우는 것과 같았습니다 . 변경된 파일을 수동으로 찾고 압축하여 이메일로 전송하고 소스 볼트 시스템에 원격으로 연결 한 후 압축을 풀고 소스 볼트 시스템에서 코드를 체크인하는 것이 더 빠릅니다.

Mercurial로 전환 1 분 안에 VPN을 통해 전체 소스 코드베이스를 복제 할 수 있습니다. 그리고 더 이상 분기를 두려워하지 않습니다.

다시는 돌아 가지 않습니다.

혐오입니다. 그러나 여전히 아무것도 아닌 것보다 낫습니다.

개인적으로 어떤 문제도 경험하지 않고 오랫동안 (약 10 년 동안) 사용했습니다 (내 코드가 충돌 등을 피하기 위해 상당히 잘 분할 된 경향이 있지만 작업중 인 팀 포함).

그러나 믿을만한 오픈 소스 대안이있을 때 데이터를 계속 사용하기에는 너무 많은 데이터 손실 사례가 있습니다.

편집 : 의견에서 메시지는 복잡한 것을 피하는 것처럼 보입니다 (분기, 병합, 충돌). 더 중요한 것은 위험한 지역으로 향하고 있습니다.

MS조차도 TFS를 선호하여 더 이상 사용하지 않습니다.

Visual Studio 6 또는 그보다 오래된 것에서 일하는 독창적이거나 작은 상점의 경우 통과 할 수 있으며 아무것도 아닌 것보다 낫습니다. 나는 그것이 얼마나 나쁜지에 대해 과장된 것이 많다고 생각하지만, 제품에 대한 당신의 신맛을 내기 위해 귀중한 일을 잃는 경우는 한 번만 필요합니다. VSS는 그 자리를 차지했으며 적어도 SCM 도구를 전혀 사용하지 않는 많은 개발자들에게 습관을들이도록 격려 해준 것에 대해 공로를 인정하지만, 많은 기술과 마찬가지로 이제는 거의 쓸모가 없습니다.

3 년 동안 사용하고 고급 / 합리적인 대안으로 인해 관리자에게 불만을 제기 한 후 VSS에 문제가 없었지만 옵션도 없었습니다.

내 견해로는 그것이 짜증나고 불 었다는 것이다.

가장 성가신 부분은 끔찍한 버전 관리와 혼란스러운 분기 기능이 아니라 파일 메뉴의 목록 상자에서 오른쪽 화살표 키를 눌러 확장 할 수는 없다는 것입니다.

정말 고통 스럽습니다.

VSS에 대한 나의 견해? 나는 그들이 "VSS 숙련도"를 요청했기 때문에 몇 가지 구인 제안 (매우 잘 지불)을 거부했습니다. 그리고 여기에도 같은 일을했던 다른 사람들이 몇 명 있다고 확신합니다.

잠재적 인 소스 손상 문제 (관리자가 소스를 대체하기에 충분한 논거)를 겪을뿐만 아니라 어색한 백업과 함께 다른 작업 스트림의 팀으로 효과적으로 작업 할 수 없어야합니다.

다른 SCM (다른 하나)을 찾아 분기 및 병합이 얼마나 쉬운 지 살펴보십시오. VSS 솔루션에서 파일을 복사하고 '제작'코드의 버그를 수정하기 위해 되돌아가는 동안 다른 곳에 보관해야 할 때를 생각해보십시오.

킥을하려면 GIT를 설치하십시오. VSS 파일을 가리키고 GASP 두 프로그래머가 같은 파일의 다른 부분에서 같은 시간에 작업 하는 것이 얼마나 쉬운 지 확인한 다음 소프트웨어가 변경 사항을 지능적으로 병합하도록하십시오 ... SCM 도구는 단순한 소스 백업 이상이어야합니다.

VSS에 대한 나의 견해? 오랫동안 정기적으로 사용했지만 (이전 구성 요소의 경우 때때로 사용됨) 우리 팀에게는 너무 XX 세기입니다.

• 매우 신뢰할 수없는
• 사용할 수없는 지점
• 매우 나쁜 버전 관리 지원, 레이블이 있지만 분기와 마찬가지로 실제로 사용할 수는 없습니다.

나는 위의 모든 것을 가지고 있습니다 : 더 나은 오픈 소스 대안 중 하나 (오래된 CVS) 중 하나를 선택하거나 회사에 MSDN 구독이있는 경우 TFS를 선택하십시오 .

• 기본 잠금은 개발자의 속도를 늦추고 있었고 아무도 설정을 망치고 싶지 않았습니다.
• 프로젝트 관리 웹 애플리케이션과 같은 다른 서비스와 잘 통합되지 않습니다.
• 계획된 CI 서버와 잘 작동하지 않았습니다.

새로운 2010 Team Foundation은 많은 도움이되었고 VSS의 나쁜 부분에서 벗어나려고했습니다. 그러나 핵심은 여전히 ​​VSS에 의존 하기 때문에 우리는 SVN으로 옮겼습니다.

편집 -나는 TFS가 완전히 새로운 것을 이해하지만 테스트 할 때 여러 개발자가 비슷한 느낌을 가졌습니다. 내가 '핵심'이라고 말한 이유는 VSS와 같은 모양의 솔루션에서 만든 TFS 파일을 보았 기 때문입니다. 이것은 VSS, TFS 또는 다른 SCM의 기술에 대해 알지 못하는 개발자의 관점에서 비롯된 것입니다. 혼란을 드려 죄송합니다.

그날 저는 XENIX에서 SCCS로 안장을 쳤습니다. Visual Studio 6에서 VSS는 모든 실패와 문제로 인해 뚜렷한 이점이있었습니다. 나는 여전히 소규모 프로젝트에 사용하며 더 이상 모든 버전에서 SCCS를 사용하지 않습니다.

왜 모두가 VSS를 악용하고 싶어하는지 알 수 없습니다. VSS는 배포되지 않으며 분산 버전 제어는

1. ...보다 나은
2. 실제로 비 분산 버전 제어 가능

이것을 읽으십시오 .