>VSS allows concurrent modifications and merges.
>
>IDE integration and checkin/checkout model are key to me. I strongly dislike the distributed model.
>

Tuvia, I've used VSS for more than 17 years, so that's why I can compare VSS with newer tools.

In this model of work, if one developer takes vacation leaving files blocked, your project in literally blocked if you don't have this user's password, which can be something illegal in some countrys.

Another problem is that while one user is blocking a file (typically a form or important core library) then some part of the team can be blocked too, but the worst case in this scenario is when you externalize partial evolutions of the whole application, let's say 2 teams geaographically distributed, and both need to modify the same component. If you don't allow concurrent modification on components, then the development velocity decreases notably because of this blocking scheme.

But if you have a small team and have a perfectly separated application, then you can keep working old style.

Have you tested working with a distributed model? I'm doing it, with VFP, almost a year now, and can't (and won't) go back again.


I describe you a typical scenario with this (my day to day):

We have an old application started in VFP 6 and migrated to VFP 9 back in 2008 with 1,5 millon lines of code distributed on main core application and some satellite components, using SourceSafe from 2001 up to last year (2013). In all this years the merge was manual (you know, open form or class, find the modified method, copy the modified code and past on destination form or class), hours doing that way because maintainment was externalized and there were up to 2 teams than can modify same components, each one having to talk with the another team so they can "turn" for modifying some components. Was really a hell, and from time to time some parts of the VSS history was misteriusly "gone" (you can never get back those history files).
Petitions of new functionallities were difficult to sincronize between teams, and we didn't use VSS branches because they were a nightmare

From this year we are using a DVCS (Plastic), each new functionality is developed in a separated branch and various functionallities are included in releases.
Each functionality is tested in separated tasks, and functionalities are tested merged on the release too.
The case is that some of this functionalities take more time than others (let's say, 3 or 4 weeks) and sometimes there is no time to finalize some of them for the Release date, so we need to take out this functionality of the release, but keep for the next one. We can do this without problems, and we can merge changes on same components without problems too. Development time is faster now that a year ago, and the Integration of code is done in 1/10th of the time it toke on VSS with the blocking model of working.

As you can see, we are very happy with this enhancement on the development, plus we have now many tools included with the DVCS that up to last year sounded as SciFi for us.

Well, I hope that this can give some light on how is working with the DVCS model. It's really great.

Best Regards.-