내 팀이 sourcesafe를 삭제하고 SVN으로 이동하도록 어떻게 설득합니까?

내 팀이 sourcesafe를 삭제하고 SVN으로 이동하도록 어떻게 설득합니까?

---

우리 개발 팀은 매우 기본적인 수준에서 소스 안전을 사용합니다. 우리는 좀 더 발전되고 확장 된 개발 주기로 이동하고 있으며 변경 사항을 관리하기 위해 분기 및 병합을 사용하지 않는 것이 곧 우리를 괴롭힐 것이라고 생각합니다.

팀이 SVN과 같은 더 나은 솔루션으로 이동하도록 설득하기 위해 가장 유용한 주장은 무엇입니까?

팀이 ide sourcesafe 통합을 놓치지 않도록 기능 격차를 해소하기 위해 어떤 프로그램을 사용 했습니까?

아니면 그냥 sourcesafe를 받아들이고 더 나은 방법을 시도해야합니까?

---

먼저, SourceSafe를 효율적으로 사용하는 방법을 가르치십시오.

그들이 충분히 똑똑하다면 버전 관리 시스템 사용의 장점을 좋아하게 될 것이고, 그렇다면 곧 SourceSafe의 한계에 도달하게 될 것입니다. 팀이 달성 할 준비가 된 것에 따라 더 나은 VCS로 전환하는 것에 대한 귀하의 주장을 더 잘들을 수있는 곳입니다. CVCS 또는 DVCS가 될 수 있습니다.

소스 코드의 zip 파일을 저장하는 것과 같이 잘못된 방식으로 SourceSafe를 사용할 때 다른 VCS를 사용하도록 강요하려고하면 (웃지 마세요. 2 년 전에 저희 회사에서 그렇게 행동했습니다) 완전히 꺼릴 것입니다. 가능한 한 좋은 논쟁에.

---

신뢰할 수 있음

• SVN은 대규모 데이터베이스에서 훨씬 더 안정적입니다.
• SVN은 여전히 ​​적극적으로 지원됩니다.
• 원자 적 커밋-VSS에서 다른 사용자가 체크인을 수행하는 동안 최신 버전을 가져 오면 일관성이없는 상태가되어 더 나은 경우에는 "최신 버전 가져 오기"를 반복해야 할 수 있습니다.하지만 불행한 경우에는 코드베이스가 남아있을 수 있습니다. 컴파일되지만 작동하지 않습니다. 이것은 원자 적 커밋 덕분에 SVN에서 발생할 수 없습니다.

풍모

• SVN 분기 / 병합이 훨씬 좋습니다.
• SVN은 원격 액세스를 기본적으로 지원합니다.
• SVN은 더욱 구성 가능합니다 (외부 Diff / Merge 도구 통합).
• SVN은 더 확장 가능합니다 (후크).

생산성 향상

• SVN "업데이트"는 SS "최신 버전 가져 오기 "에 비해 훨씬 빠릅니다.
• SVN 명령 줄은 훨씬 쉽고 깔끔합니다. 자동화 된 빌드 또는 테스트 도구에 유용합니다.

동일한 수준의 IDE 통합

• VSS는 최근까지 훨씬 더 나은 VS 통합을 제공했지만 AnkhSVN 2.0 에서는 더 이상 사실이 아닙니다.

열다

SVN은 열려 있으며 SVN을 사용하거나 협력하는 다양한 도구가 많이 있습니다. 몇 가지 예는 다음과 같습니다.

• 많은 버그 추적기 또는 제품주기 관리 제품과 통합
• 쉘 통합
• 다양한 제품에 통합
• 다양한 관리 및 분석 도구
• 소스를 사용할 수있는 경우 필요에 맞게 조정하고, 문제를 해결 (또는 필요한 경우 누군가를 고용) 할 수 있습니다.

비용

• 라이센스 또는 유지 보수 비용을 지불 할 필요가 없습니다.

---

C # 코드에서 비 ASCII 문자를 사용 하기위한 몇 가지 핑계를 찾으십시오 (중국어와 일본어가 이에 적합합니다).

SourceSafe는 유니 코드를 좋아하지 않습니다 (Visual Studio가 그렇더라도). 따라서 올바른 유니 코드 텍스트를 선택하고 파일을 체크인 및 백 아웃하면 전체 파일이 손상된 의미없는 말로 나타납니다. 이것의 장점은 SS가 "diff"버전 관리 시스템을 사용하기 때문에 실제로 파일을 원래 체크인 버전으로 완전히 손상시키고 자동으로 수정할 수 없다는 것입니다.

이것이 한 번만 발생하면 (일본어를 지원해야하는 응용 프로그램에서 작업 할 때와 마찬가지로) SourceSafe를 삭제하는 결정적인 주장이 될 것입니다.

---

VSS를 통해 SVN에서 관리 및 팀을 판매하는 데 사용한 두 가지 기능이 있습니다.

1) 분기 능력. VSS를 사용할 때 릴리스가 나가도록 예약되었을 때 릴리스가 실제로 나가기 전까지 전체 저장소가 잠겼습니다. 여기에는 테스트 및 수정주기가 포함되었습니다. 따라서 개발자는 릴리스에 대한 수정 사항 외에는 VSS 저장소 에 커밋 할 수 없었습니다 . 이로 인해 각 릴리스 직후 긴 통합 세션이 발생했습니다. SVN에서 릴리스 분기를 사용하면 더 이상 전체 저장소를 잠글 필요가 없습니다.

2) 전체 변경 사항을 한 번에 롤백하는 기능. SVN은 단일 원자 적 커밋에서 변경된 모든 파일을 기록하기 때문에 문제가있는 변경 사항을 되 돌리는 것은 간단합니다. VSS에서 개발자는 전체 저장소를 살펴보고 거의 동시에 변경된 모든 파일을 찾아서 각 변경 사항을 각 파일로 개별적으로 되돌려 야했습니다. SVN을 사용하면 관련 커밋을 찾고 TortoiseSVN에서 "Revert Changes from this Commit"버튼을 누르는 것만 큼 간단합니다.

참고로, 우리는 TortoiseSVN을 사용하며 모든 사람 은 변경된 내용과 변경되지 않은 내용을 확인하기 위해 파일 오버레이 아이콘을 좋아 합니다.

---

무엇을 하든지 천천히 움직 이세요! 첫째 날에 분기에 대해 이야기하기 시작하지 마십시오. 나는 그 코멘트로 VSS 사용자를 고정 관념하고 있지만 그것이 내가 거기에서 보는 것입니다.

개발자를 위해 : 더 빠르고 더 잘 작동하는 VSS의 대체품으로 판매하십시오. 1 일차에 VisualSVN을 사용하여 매우 얕은 학습 곡선을 갖도록합니다. 더 빠르고 안정적이며 두 사람이 같은 파일을 편집 할 수 있다는 점을 제외하고는 동일하게 판매하십시오. 일부 사람이 여러 파일을 잠근 상태로 병에 걸리는 문제가 발생하지 않습니다.

관리자를 위해 : VSS보다 더 안정적이고 관리하기 쉬운 곳에 판매하십시오. 그들에게 VisualSVN 서버를 보여주십시오 .

행운을 빕니다!

---

먼저 소스 제어 시스템 내에서 근본 원인으로 추적 할 수있는 모든 문제를 문서화하십시오. 한 달 정도 추적하십시오. 그것을 사용하지 않아서 놓친 기회에 추가하십시오. (“Subversion을 사용하지 않는 기회 비용”이라고 말하면 MBA 유형의 관리자에게 깊은 인상을 줄 수 있습니다.) 이 수치는 실제로 기회 비용을 과소 평가 한 것입니다. 아마도 VSS를 엉망으로 만들지 않았다면 시간당 요금보다 더 많은 것을 제공 할 수 있었을 것입니다.

예를 들어, 여러 사람이 액세스해야하는 파일이 잠겨있는 문제가 있습니까? 부분 (비 원자) 체크인에 문제가 있습니까? 소프트웨어 릴리스를 추적하고 과거와 마찬가지로 리포지토리를 다시 생성하기 어려운 문제가 있습니까? 소스 세이프 클라이언트가없는 서버로 코드 사본을 가져 오는 데 문제가 있습니까? 지속적인 통합 도구가 버전 제어 시스템의 업데이트를 모니터링 할 수 없기 때문에 빌드 및 테스트 프로세스를 자동화하는 데 문제가 있습니까? 나는 당신이 다른 많은 것을 생각할 수 있다고 확신합니다.

소스 세이프 (sourcesafe)로 인한 문제의 대략적인 시간 / 돈 비용과 Subversion이 제공하는 것의 이점 (인건비로 시간당 $ 100 또는 단 몇 시간과 같은 일반적인 숫자 사용) 및 프로젝트 지연 전달 비용을 파악할 수 있다면 그렇게하세요. . 한 달 정도 데이터를 수집했다면 매달 Subversion을 사용하여 이점을 보여줄 수 있습니다.

그런 다음 Subversion으로 이동하는 대략적인 시간 / 비용을 제시하십시오. (코드 설정 및 마이그레이션에 약 8 시간, 개발자 당 연결, 체크 아웃 및 프로젝트 이동에 2 시간 소요) 소스 세이프가 여전히 롤백 할 수 있기 때문에 위험이 낮습니다.

비용이 월간 혜택보다 많으면 비용을 혜택으로 나누어 회복 기간을 알아낼 수 있습니다. 또한 장기적인 이점을 보여주기 위해 3 년 정도에 걸쳐 합계해야합니다. 다시 말하지만, 소스 세이프에서 분기되지 않은 릴리스를 관리하는 동안 가치를 추가 할 수 있었기 때문에 실제 기회 비용을 직접 계산할 수 없다는 점을 강조하십시오.

---

아무도 SourceSafe 사용을 권장하지 않습니다. Microsoft도 마찬가지입니다. 이제 대신 (비싼) TFS 라이선스를 제공합니다. SourceSafe는 신뢰할 수 없습니다.

나는 여기에 그것에 대해 썼다 : Visual SourceSafe on E2 . 약간의 폭언이지만 SourceSafe를 꽤 오랫동안 사용해야했기 때문입니다. 그리고 메모리는 입에서 약간의 거품을냅니다.

신뢰성은 당신을 물릴 가장 큰 것입니다. 또한 SVN 또는 TFS에서 높이 평가할 수있는 기능이 있습니다.

TFS와 SVN은 둘 다 여러 파일의 원자 적 커밋을 가지고 있지만 Sourcesafe는 그렇지 않습니다. 두 파일을 "한 번에"체크인하면 하나의 작업이 아니라 파일 중 하나를 체크인 한 다음 다른 파일을 체크인하는 것과 동일합니다. 한 파일이 체크인되었지만 다른 파일은 체크인되지 않은 중간 상태에있을 수 있습니다.

SourceSafe는 삭제 된 파일, 파일 이동 또는 이름 변경 기록을 보관하지 않습니다.

초기 노출과는 달리 SourceSafe는 올바른 옵션을 설정 한 경우 동일한 파일의 여러 동시 체크 아웃을 지원합니다. 그러나 TFS 및 특히 SVN은 이러한 작업 방식에 더 적합하게 설계되었습니다.

SourceSafe와 달리 TFS와 SVN은 모두 인터넷의 서버에 대해 잘 작동하며 (TFS는 괜찮음, SVN은 훌륭함) SVN은 오프라인에서 잘 작동합니다. 예를 들어 비행기 나 기차에 노트북이 있고 'net이없는 경우에도 여전히 작업하고 비교할 수 있습니다. 할 데이터가 로컬에 보관되어 있기 때문에 이전 개정으로 변경하거나 되돌릴 수도 있습니다.

다른 누군가가 지적했듯이 CVS와 마찬가지로 SourceSafe는 "죽은"제품입니다. 적극적으로 개발되고 있지 않습니다. TFS 및 SVN은 향후 언젠가 다음 버전을 출시 할 예정입니다.

---

VS 용 AnkhSVN 플러그인은 꽤 좋습니다. 몇 가지 이상한 점이 있지만 전체적으로 잘 작동합니다.

팀이 움직 이도록 설득하는 것은 힘든 일입니다. 저는 그것을 관리 한 적이 없습니다 :-( 아마도 속도가 더 실용적인 주장 중 하나 일 것입니다.-VSS는 1GB 소스 데이터베이스와 여러 사용자가있을 때 느립니다 .

편집 VSS를 사용한 지 너무 오래 되었네요. 잠긴 것을 잊었습니다! 예, 여기에서 언급했듯이 비 독점 / 병합 변경 모델로 전환하는 기능은 개발자가 많지 않은 경우 도움이 될 것입니다. 사무실에서 "누군가 공통 포함을 확인할 수 있습니까?"라고 외치는 것을 방지합니다!

---

"팀이 SVN과 같은 더 나은 솔루션으로 이동하도록 설득하기 위해 가장 유용하다고 생각한 주장은 무엇입니까?"라고 말합니다.

그것이 더 나은 해결책이라는 것을 모른다면 왜 논쟁을 벌이고 있습니까? 당신의 마음이 해결책을 위해 논쟁 할만큼 충분히 구성되어 있다면, 그 이유가 이미 무엇인지 알아야 합니다.

What convinced you that you should move to something better? Those are your arguments right there. Anything short of those arguments will sound like it's just an issue of personal preference.

---

TortoiseSvn (free) is really nice for explorer integration, giving you all the features of svn from a context menu.

VisualSvn (commercial) makes it just as easy to integrate svn into Visual Studio, with the same status indication in the solution browser as well as context menus to use all the subversion features.

Both these tools go a long way to making version control seamless. It's been a coupe of years since I dealt with VSS, but these tools are a way nicer way to use source control.

Ditto for what every one has said about VSS being poop

Subversion has good support for branching and doing merges... I don't remember VSS having any capabilities in this department at all. I do remember teams going through pain of week long merges when needing to release from VSS, pain which just doesn't exist anymore with Subversion.

---

First search google for the sheer quantity of pages describing how bad VSS is and share that with your coworkers.

Second, skip subversion and go straight to a proper distributed SCM like git or mercurial. Because merging is such an inherent part of distributed SCMs, they have to handle merges much better than centralized systems like svn. Subversion is still trying to retrofit itself to handle branching better, where the distributed systems were built correctly to begin with.

---

Build some automation that mirrors the VSS repository into a SVN repository

It takes time to build a consensus. If your SVN mirror of the VSS repository is available at all times, it will be easier to accumulate converts. The mirror doesn't have to be perfect- it just has to be usable. There are existing tools for this purpose.

---

Tell them to treat the source code as if it was money and point them to the numerous examples of SourceSafe coming down in flames taking the source with it. Things like that are just not supposed to happen in a proper source control system.

The best argument against SourceSafe is that it is just isn't Safe, everything else can potentially be called "features we don't need".

---

The clincher for us was the speed (i.e., the lack thereof) of VSS over VPN and low bandwidth hotel networks on the road and the problems of trying to tunnel through firewalls so that two teams at two different sites could quickly, securely, and reliably work from the same code repository. We were running two VSS repositories and packaging up "deliveries" that had to be merged into the other site's repository to keep them in sync.

The team grumbled for a while, but quickly got over it. TortoiseSVN is fantastic by itself and the AnkhSVN plug-in for Visual Studio really eased everyone into the changeover.

Looking back, I can't believe how many "Can you check in file SoAndSo?" e-mails we sent around, not to mention the "SourceSafe is down. We've got to restore the repository" e-mails.

Sheesh. After reading this comments and writing this response, I can't believe we put up with VSS for as long as we did.

---

Web page summarising problems with VSS - just point people to that URL

---

If you use VisualSVN the team won't miss VSS as much. 2 people being able to work on one file at the same time is a big selling point too.

---

The unreliability of source safe ("please fix the repository...") was enough of a sell for us. Andecdotally (I've never measured it) SVN also always seems faster. Good concurrent checkouts / merging.

I'd always figured that to a developer it was almost too obvious. SourceSafe just seems to break and die all too often to not want to replace it...

---

Tell them to read this http://www.highprogrammer.com/alan/windev/sourcesafe.html

---

I would recommend that you go ahead and start introducing best practices to your sourcesafe usage with a view to changing to subversion further down the line. Hopefully this will make your actual subversion migration easier and give you time to sort plan out your development cycles, branching strategies et al. properly.

The other thing to consider is your development process in general. A source control management system is only ever part of the solution, to get the most out of subversion or any other product you will probably want to look at how it's usage interacts with your code review, qa and build processes.

---

I don't remember any SourceSafe user ever liking the product. Do your colleagues actually like it?

I've got a similar issue with CVS at my current customer's usage. Since "it works" and they are mostly pleased with it, I cannot push them to change. But daily I sure wish they would!

---

When I was at the launch for VS2005 I managed to corner a Microsofty and ask why SourceSafe was so awful to use. The reply I got was rather shocking, not just because of what he said but because he was so up front about what he'd said.

He told me that it was only really meant for one person to use and even then it wasn't very good at doing that.

My colleagues and I were a bit shocked we couldn't think of much else to do other than laugh out loud, as did the Microsofty! He then told us that it wasn't used internally.

So, we switched to subversion shortly after that. We'd pretty much decided to go for it before the launch event, but that just confirmed we'd made the right decision.

---

We used to use SourceSafe. Then, when I joined the team I was in a different location and even though we have a fairly good LAN when I tried to check out the latest version it took 40 minutes. I persuaded them to convert to CVS (we now use SVN) and the checkout time dropped to a couple of minutes. SourceSafe was just too slow to be usable at a remote location.

---

We moved from SourceSafe to Source Gear Vault. This source control engine is very comfortable for some one used to SourceSafe. We finally decided to make the change after a couple SourceSafe corruption incidents, that came at critical times. So my advice would be to focus your sales presentation on SourceSafes unreliability.

---

Surely using source safe is enough reason to want to migrate to another source control system?

I used SVN and CVS at my old job and have moved to a company that uses Source safe (we are going to migrate to SVN) and just using VSS has been enough for me to take a serious dislike to it. I went in with an open mind, despite many of my colleagues from my previous job telling me horror stories about VSS I assumed that it would have gotten better since they used it.

Not being able to edit a file because somone else is/was editing it is ridiculous. I've tried to move to more distributed versioning systems like Bazzar which is made by cannonical however it's not mature enough in terms of the tools available.

Source safe gets in the way of development where SVN helps you almost every step of the way.

Plus Using tortoise Svn made code reviews a lot easier.

---

Only to the extend as you are able to herd a bunch of cats. I've been there twice and in both cases it took some serious problems in Source Safe before people saw the light. As a manager on the other hand I simply directed the team to use SVN and our productivity increased by 300% ( this was working with a group in India and in the US. We had code exchanges that used to take a long time before svn )

---

Also Trac mounts on top of Subversion. It's free and a great way to view the repository (timeline, wiki, etc)

---

As you're making these arguments, consider whether you need to address any policy your company may have about using open source tools. See this answer to a prior question: Switching source control

---

Make them use it and they will switch to something else :)

Now, being serious, tell them its not that hard to use it, many developers that I've known refused to switch because they related subversion to unix and wierd commands, show them interfaces like ToirtoiseSVN or VisualSVN, tell them that Subversion allows them to edit the same file withouth a forced locking like VSS does.

And last but not least, it is Open Source. It has lower cost than buying Team Foundation Server and if you look around you will see that small teams of developers work quite well with SVN.

---

I used SourceSafe on a small development team and was responsible for keeping it running.

I found the database gets corrupted pretty easily, and there isn't much recourse when that happens. The "repair" feature (as with most any Microsoft repair feature) just doesn't work 98% of the time.

Naturally, when our database became corrupt, we tried to restore from our backup archive. That was when we discovered the other bad thing about SourceSafe: its 2GB archive limit. We were making backups at our office for months before we ever realized that they couldn't be restored and were useless.

SourceSafe is just a disaster waiting to happen.

---

I'm planning on ditching SourceSafe in the next few weeks, after over a decade of putting up with it. Mostly I've been using it within the context of a small (< 5 person) team, and not had to do a lot of branching because there's been no call to do it.

However, the #1 problem for me, and always has been, is that the damn thing is so prone to corruption - if you have your SS database (lol, database; collection of randomly named files more accurately describes it) on a network drive, and something happens to your LAN connection partway through an add/checkin operation - 9 times out of ten you get "invalid handle" and the damn thing is corrupted in some way, and then you get to play Russian Roulette with the Analyzer tool.

I realised, a couple of months back, that for the past decade I had been making local zipped up copies of the source at every release of the software I was working on, because I didn't trust the source control system. What a waste of time.

So, it's going. I'll probably use Subversion and TortoiseSVN, because I think the team will need a UI to ease the transition.

참고URL : https://stackoverflow.com/questions/115493/how-do-i-convince-my-team-to-drop-sourcesafe-and-move-to-svn