On 9/25/07, Bryan Petty <[EMAIL PROTECTED]> wrote: > On 9/25/07, jtaber <[EMAIL PROTECTED]> wrote: > > I would prefer #3. with the improvement of distributed version control > > such as Mercurial and Bazaar, I don't even think SVN is a very good > > choice for most shops and especially for smaller developers. > > On the contrary, Subversion is making some interesting headway in the VCS > world. > > 1.5 will have merge tracking, transparent mirroring, incomplete > checkouts (read: CVS modules functionality), and interactive conflict > resolution on update. > > Features on the roadmap include offline commits, local branches, and > hybrid distributed/centralized repositories. So it will be in > competition with every other distributed VCS soon enough. > > SVN is still the replacement choice for many projects (including open > source projects) migrating off of CVS despite not having any of these > features yet. I still prefer SVN over any other VCS even for my small > projects. Even projects not using SourceForge still prefer SVN with > most of the biggest projects in tow [1] including ASF, Gnome, KDE, > GCC, and Python. I only mention this because SF is ridiculously slow > at rolling out new systems for use, and still only offers CVS and SVN, > so many choose SVN just because they don't have a choice (not that I > see this as a bad thing). > > [1] > http://subversion.tigris.org/testimonials.html#open-source-projects-using-svn > > And as far as small developers getting started in the VCS world, it's > (IMHO) the easiest to learn, and has the best GUI clients. I still > haven't seen anything that beats TortoiseSVN or even comes close for > that matter. > > Besides, distributed VCS models aren't really a good choice for > proprietary development models. > > Now, I don't advocate projects using SVN if they really do need a > distributed VCS model right now, but it's not as necessary as most > people are led to believe, and in many cases, it just slows down > development. > > I also have the impression that SVN has better/wider integration with > various tools like bug and patch trackers (Trac is a good example, > having SVN support well before Bzr or Mercurial have been added as > plug-ins in the newest versions), diff viewers, IDEs (not counting > unofficial support, Visual Studio may like sticking with MS's > proprietary VCS, but Xcode supports SVN, and not any of the > distributed VCSs), and other development tools. And yes, I consider my > svnLogBrowser tool in this category. Given the name of the project > (and yes, I had thought of this before), I don't plan on ever having > Bzr or Mercurial support. ;) > > So I don't really share your opinion on this subject. > > Regards, > Bryan Petty
Bryan, I completely agree. To me there are different uses for local version control versus distributed. If you are just working on a project with a few people svn is great. On the other hand if you have 20 people working on a project that don't have regular network access. There are definitely advantages/disadvantages to both, though usually lately, I've been a big fan of distributed source control for most of my projects. Cheers, Clint _______________________________________________ UPHPU mailing list [email protected] http://uphpu.org/mailman/listinfo/uphpu IRC: #uphpu on irc.freenode.net
