Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Current scctext text generator replacement
Message
From
15/10/2014 15:29:56
Lutz Scheffler
Lutz Scheffler Software Ingenieurbüro
Dresden, Germany
 
 
To
15/10/2014 14:00:07
General information
Forum:
Visual FoxPro
Category:
Source Safe Control
Environment versions
Visual FoxPro:
VFP 9 SP1
OS:
Windows 7
Network:
Windows 2008 Server
Database:
Visual FoxPro
Application:
Desktop
Miscellaneous
Thread ID:
01599986
Message ID:
01609479
Views:
43
VSS? 16 Years of it, 1 time file coruption (with going deep into those little aaabbb files) a lot of undelatable junk. More or less trustworthy.

Biggest backdraw:
I was cast into independece without warning. Had nothing then my home comp, some software licenenses and the code I've worked the last dozen years (customer owned) I've tried to set up VSS on my little Marvel NAS - Never made any problems with local file sharing etc. One must have seen it on VSS files. Net down to 5% CPU to 100%, 10 min to open a project. Not to mention checkout or refresh. Just not enough poer to handle the thousends of little files ...

And I hate the offline behaviour.

We ever worked with vcx as it comes, multiple checkout was never an issue due to clever vcx design. :)

Will move to git this year, this integrates fine with my 'Nix stuff.


>You make a good case, I will consider it.
>
>(Note: using multiple checkouts is a requirement for proper VFP/VSS project integration, so we always did that. No blocking. And maybe Sourceoffsite makes a difference, but we have used branching and just about every VSS feature for 10 years and have never had so much as a corrupted file. I hear stories abhout VSS nightmares, but here it has worked like a charm.)
>
>
>>>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.-
Words are given to man to enable him to conceal his true feelings.
Charles Maurice de Talleyrand-Périgord

Weeks of programming can save you hours of planning.

Off

There is no place like [::1]
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform