문제

제가 현재 근무하고 있는 곳은 현재 전환 중이고, 새로운 소유권이 인수되었으며, 마침내 모든 것이 표준화되고 적절한 지침이 시행되고 있습니다.

하지만 우리는 여전히 VSS를 사용하고 있습니다. 초기에 설정된 것 외에는 사용할 이유가 없습니다.우리는 Visual Studio나 이를 특별히 요구하는 도구를 사용하지 않습니다.

장기적으로 보면 Subversion과 같은 방식을 사용하는 것이 훨씬 더 나은 솔루션이라는 점을 고객에게 확신시키기 위해 제가 제시할 수 있는 가장 좋은 주장은 무엇입니까?

도움이 되었습니까?

해결책

VSS는 데이터베이스 관리를 전적으로 클라이언트에 의존합니다.클라이언트가 네트워크를 통해 쓰기 도중에 잘못된 시간에 연결을 끊으면 파일이 서버에서 삭제됩니다.팁뿐만 아니라 모든 역사.잘 백업하시길 바랍니다.나는 그것을 겪었습니다.나쁜 소식이에요.

VPN이나 ​​기타 원격 연결을 통한 VSS 사용량은 매우 적습니다.데이터를 전송하기 위해 SMB를 사용하고 있으며 팁을 얻으려면 파일과 모든 델타를 검색해야 합니다.끔찍한.

VSS가 1GB의 데이터로 작동하기 시작하는 것을 보았습니다.데이터베이스 오류 등MS(FAQ 또는 KB 어딘가)에서는 2GB가 실제로 최대 안전 한도라고 말합니다.좋은 관리 도구가 없기 때문에(클라이언트가 망명을 운영함) 실제로 이에 대한 경고를 받지 못합니다.

아무것 일정 수준의 트랜잭션과 무결성 제어를 제공하는 서버 프로세스를 사용하는 것이 우수한 솔루션입니다.

다른 팁

가장 좋은 주장은 그들이 Subversion으로 전환하기를 원하는 이유여야 합니다.:)

나는 VSS에 대해 전혀 모르지만 "깨지지 않았다면 고치지 마십시오"라는 문구가 떠오릅니다.VSS가 손상되어 수정이 필요하다는 사실을 관리자에게 보여주어야 합니다.경영진에게 어떻게 돈을 절약할 수 있는지 보여줄 수 있다면 더욱 좋습니다.

@아담 데이비스:어, 실제로 Adam, VSS는 끔찍한 소스 제어 시스템입니다.역사를 손상시키고 데이터를 잃어버린 오랜 역사를 가지고 있습니다.병합이 끔찍하고 여러 개발자를 잘 처리하지 못하며 매우 느립니다.또한 역사도 좋지 않습니다.Microsoft는 더 이상 이를 지원하지 않으며 자체 내부 개발에 사용한 적이 없으며 이제는 더 현대적인 솔루션(VSTS)을 선호하여 판매하지도 않는다는 점을 알게 될 것입니다.즉, VSS와 다른 유형의 소스 제어 중에서 선택해야 한다면 대안을 선택하세요.

좋은 소스 제어 기능을 살펴보면 다음과 같은 이점이 있습니다.

  • 누가, 언제, 어떤 순서로, 어떤 파일을 처리했는지에 대한 로그를 쉽게 볼 수 있는 기능
  • 모든 것의 과거 버전 기록을 유지
  • 쉽게 돌아가서 이전 버전에서 특정 버전의 파일을 재현하여 이전 버전에서 보고된 버그를 보다 쉽게 ​​재현할 수 있습니다.
  • 프로세스 중 데이터 손실에 대해 걱정할 필요 없이 삭제된 코드를 검색하거나 원치 않는 변경 사항을 제거할 수 있습니다.

전환을 증명하는 모든 문서는 비용을 절감합니다.실패하면 다양한 색상의 그래프와 차트가 표시됩니다.어쩌면 파워포인트 프레젠테이션일 수도 있습니다.

인터넷에는 VSS의 결함에 대해 잘 쓰여진 기사가 넘쳐납니다.나는 이것을 VSS에서 벗어나기 위한 증거 자료로 수집할 것입니다.VSS가 지원할 수 없는 주요 요구 사항(원격 작업, 다른 OS에 대한 지원, 도구 통합)을 찾아 이를 사용하여 문제를 해결하세요.그런 다음 조직의 요구 사항에 잘 맞는 소스 제어 시스템을 찾아야 합니다. Subversion이 해당 시스템이라고 확신합니까?선택한 시스템의 데모를 설정하고 이를 사용하여 그 가치를 입증하십시오.

나는 이전 고용주(처음에는 CVS, 그 다음에는 SVN)에서 이 변경 사항을 구현했으며 성공했지만 가장자리 주변에 많은 비트를 구축하고 많은(때로는 신뢰할 수 없는) 오픈 소스 프로젝트에 의존해야 했습니다. 우리에게 필요한 모든 도구.돌이켜보면 Perforce, Vault 또는 Team System과 같은 전문 도구를 평가하는 것을 고려했어야 했습니다.이를 평가한 결과 CVS/SVN이 "무료" 가격표만큼 가치가 있는지에 대해 적절한 가치 판단을 내릴 수 있었습니다.

분기와 분기를 처리할 수 있는 것이 시작입니다.

한동안 vss와 병행하여 Subversion을 사용해 보면 상사를 설득할 수 있는 많은 주장을 발견하게 될 것입니다.그렇지 않다면 상사가 옳으니 바꿀 이유가 없습니다.

'vss 문제', '소스 안전 손상'에 대해 Google에 검색하거나 간단히 Wiki 페이지를 살펴보세요.이는 귀하가 비즈니스의 중요한 부분을 베팅하는 것이 아마도 장기적으로 실행 가능한 일이 아닐 것이라는 점을 그들에게 확신시켜야 합니다.

당신의 팀 규모는 얼마나 됩니까?(즉, 샐러드 다저인지 여부가 아니라 회원 수를 의미합니다.) 일단 상당히 활동적인 사용자가 6명 이상이 되면 VSS는 골치아픈 일이 될 것입니다.

저는 Microsoft가 이를 사용하는지 심각하게 의심합니다(사실 그들은 맞춤형 Subversion이나 CVS 변종을 사용하지 않습니까?). 그리고 여러분은 스스로에게 물어봐야 합니다. 회사가 자체 dogfood를 먹지 않는다면 왜 여러분이 그것을 먹겠습니까?

기본적인 대답은 전환이 비즈니스 요구 사항을 충족시키는 경우를 만들어야 한다는 것입니다.예를 들어:

  1. 개발 비용 절감
  2. 더 짧은 일정(#1의 또 다른 색상)
  3. 프로세스 요구 사항(예: 소프트웨어 요구 사항 추적성 또는 빌드 재현성 등)을 충족하는 데 더 적합합니다.

이러한 사실을 입증하려면 "우리는 비용을 낮출 것입니다. 오른쪽 할 수 있는 방법!".

주의해야 할 한 가지는 개발자가 기본 비즈니스 필터를 먼저 거치지 않고 변경하는 것이 유익할 것이라고 스스로 확신하기가 너무 쉽다는 것입니다.그런 일이 발생하면 개발자는 자신의 도구에 만족하지 못하고 경영진이 듣지 않을 것이라고 생각하기 때문에 두 배로 좌절하게 됩니다.위 사항 중 하나라도 체크할 수 없다면 경영진을 설득할 기회가 전혀 없습니다(경영진이 무능하지 않은 한, 이는 다른 질문입니다).

VSS를 통해 Subversion을 사용하는 이유는 무엇입니까?

  • 무료 소프트웨어
  • 관리가 더 쉬워짐
  • "체크인"은 원자!
  • 간편한 분기 및 병합
  • 지속적인 개발(예:VSS는 막다른 골목입니다)
  • 변경 사항 추적 및 로그 보기를 위한 더 나은 도구
  • 도구 세트 및 플랫폼에 구애받지 않지만 많은 도구와 통합됩니다.

나는 매니저에게 제안을 했고 꽤 쉽게 팔렸습니다.특히 분기에 사용하기가 훨씬 쉽다는 것을 알았습니다(우리 프로젝트는 VSS에서 "공유 및 고정"하는 데 5시간이 걸렸고 각 작업을 완료하는 데 추가 시간이 걸렸습니다!).

나는 이전에 쓴 VSS가 좋은 생각이 아닌 이유에 대해 설명합니다.그로부터 몇 가지 정보를 얻을 수도 있습니다.또한 이 기사 그리고 이 하나 추가 정보를 포함합니다.

VSS 2005는 6.0의 일부 문제점을 해결했지만 특별히 설득력 있는 방식은 아닙니다.동일한 뇌사 기반이 남아 있습니다.

고장나지 않더라도 VSS에서 마이그레이션하면 잠재적인 이점이 있습니다.가장 간단하고 중요한 점은 새 VSS 라이센스를 구입할 필요가 없다는 것입니다.둘째, VSS 제품에는 결함이 있는 사례가 많이 있습니다(일부는 MS에서도 인정함).SVN의 학습 곡선은 최소한 VSS만큼 낮으며, 소스 제어 시스템에 만족하는 개발자가 있다면 조기에 자주 사용할 가능성이 더 높습니다.이는 회사에 대한 위험이 훨씬 줄어들 것이며 이는 좋은 이점입니다.

@제이슨:VSS가 손상되었습니다.

VSS에서 벗어나도록 동기를 부여하는 가장 강력한 방법은 소스 코드가 얼마나 중요한 자산인지 지적하는 것입니다.정직하게 위험을 감수하는 것은 현명한 비즈니스 선택이 아닙니다.

프로그래머가 이 자산의 작성자이며, 프로그래머의 생산성을 향상시키는 것은 소스 코드 자산의 가치를 높이는 것을 의미합니다.Joel on Software는 프로그래머에 대한 투자가 회사에 얼마나 큰 승리인지 자주 이야기합니다.

여기에 있는 다른 답변은 모두 귀하의 주장을 제기할 때 지적할 수 있는 구체적인 이유를 설명합니다.

다른 답변에 제시된 기술적인 요점 외에도 다음 사항에 대응할 준비가 되어 있어야 하는 비기술적인 이유가 숨어 있을 수 있습니다.

회사에서 오픈 소스 소프트웨어에 대한 어떤 종류의 정책(또는 잘못된 두려움)을 가지고 있는지 조사해야 합니다.회사나 변호사가 독점 코드에 영향을 주지 않는 오픈 소스 코드로 무엇을 할 수 있는지 뿐만 아니라 라이선스가 독점 코드를 "감염"시키는 것과 그렇지 않은 것에 대한 자세한 내용을 이해하지 못하는 경우, 독점 도구에서 오픈 소스 도구로 전환하는 데 어려움을 겪습니다.(그리고 당신은 더 큰 교육 직업을 갖게 될 수도 있습니다.)

독점에서 전환을 주장하는 경우(예:VSS)를 오픈 소스(예:전복) 또한 코드의 품질과 코드에 관한 보증이나 기타 계약 권리의 필요성이 없음을 방어할 준비가 되어 있어야 합니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top