On Fri, Feb 4, 2011 at 2:36 PM, Lou Syracuse <[email protected]> wrote: > Well you've certainly bailed a few companies out of a SourceSafe jam over > the years, Ted. Some without even knowing it. My E-copy of your VSS book is > almost worn out. :)
Well, that's nice to hear. > I don’t see us moving out of the Micro$oft world here. And, that's too bad :) I have to say, for all the fun I had in 15 years with FoxPro, it's pretty awesome out here. > We have MSDN here, but I don't know what level. The big reason we got it > was to set up a test environment for SQL server. I asked if I could > install Visio and was turned down, still haven't figured out why... That doesn't bode well. MS has some proprietary Team Server offerings that supposedly integrate well with their tools. That's not my area any more, so I can't provide any guidance there. > I wasn't involved in the setup of SVN at Premier so I don’t know all the > details, but I know apache was involved somehow. I need to dig into it now > that I am somewhere else, and hopefully management will follow my lead. But > I don't want to lock myself into SVN based on my limited knowledge of it. > I'm getting lots of good suggestions from those using something else and > that is what I was hoping for. :) Short form of a decade long conversation: Subversion was intended as a drop-in replacement for CVS, developed by a group that was tired of some really gnarly hacks you had to go to get CVS to do simple things like renaming folders and moving batches of files. In that aspect, mission accomplished. But Subversion and CVS both adhere to the dumb-workstation-client-data-store model that SourceSafe (v.6) had as well: one central repository to rule them all. And the assumption that branching, forking and merges were things to avoid at all costs. Worked okay in the pre-distributed-Internet world, but is pretty limiting today. Today, I'm more likely to be working on a project that: - has a branch that's released to production that occasionally needs an emergency patch, which will then be backfilled through QA into the main development line. - has some older branches / tagged versions that some clients insist on not upgrading. - has two or three separate efforts to upgrade / update particular pieces of functionality, which if they work will be merged back into the next version. Some are shared between a couple developers and some are solo efforts. - another branch that an outside group is developing some new feature. Even if there's only a few of you, or even if it's just you, a good version control system can let you juggle this kind of stuff. You really want to see what distributed version control can do for you. -- Ted Roche Ted Roche & Associates, LLC http://www.tedroche.com _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[email protected] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
