Was [RE: [boost] Moving from CVS to Subversion?] Now is "Subversion experiences from the field"
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Walter Landry Subject: Re: [boost] Moving from CVS to Subversion?
David Abrahams <dave@boost-consulting.com> wrote:
I am just posting this here to alert those who look at subject lines to what we're discussing. To review the whole discussion, see http://news.gmane.org/find-
root.php?message_id=%3cuk6pujjyu.fsf%40boost%2dconsulting.com%3e
One thread you might find interesting
http://news.gmane.org/find-root.php?group=gmane.comp.version- control.subversion.devel&article=53583
It talks about the troubles Mono had in going from CVS to Subversion. YMMV.
My personal opinion is that, if you want a centralized version control system, you aren't going to do significantly better than Subversion. There are a fair number of large projects using it, and, especially with the new fsfs backend, it seems to work pretty well for most people. [Brian Braatz] I am currently running cvs and subversion side by side and wanted to share my experiences:
We have been running CVS for 4 years and SVN for about 2 CVS **** We have about 50 people hitting one server CVS seems to handle this nicely We are using cvs for 2 projects Cvs add not being recursive is a pain in the butt. I am several states away from the cvs server I am currently STILL adding boost 1.32 to a repository I started this last Friday On the SVN repository, this took a few hours (same net connection) Also the recursive "svn add" command meant I did not have to baby sit it SVN (Subversion) **************** Svn add is recursive Most of the SVN commands are very similar to cvs Seems significantly faster than cvs We had ONE instance in 2 years where we lost data- IT guys never figured out what it was- might have been a power surge or SVN we don't know We have never lost data on the cvs server We are only running about 5 guys against our svn box You can move files and retain history Retrieving files FROM history is not as simple as cvs It uses the berkely db backend Which I am not familiar with nor are my people experts in it I can "svn add" while on an airplane, but I have to be online to "svn commit" It has transactional commits- Which means if something bombs halfway through a commit- NONE of the files are added We have been bit by this one on CVS in our projects My Opinion: I like SVN, but we have not completely switched over to it For Boost, the redundant servers from sourceforge is a compelling reason to stay cvs. I am not aware if you can get the same thing from sourceforge with svn. Svn does not however tax the server as much as cvs, hence there is more client side processing Anyone else have any experience with these two side by side they wish to share?
Brian Braatz wrote:
[...] Anyone else have any experience with these two side by side they wish to share?
I've just started using SVN with some Java projects, and I have to say that the SVN integration with Eclipse is pretty good. I've never used such intuitive version control anywhere. There's a few complexities, like trying to merge changes between branches; but for the vast majority of tasks, it's a pleasure to work with. That said, I don't know how painful it is to use SVN from the command line, but TortoiseSVN is about as easy to use from the filesystem as TortoiseCVS (if not more so). The ability to store filesystem changes is a big win for SVN, IMO. I just get the impression that the overall design of SVN is more elegant and robust, since it isn't a legacy system built up out of a series of hacks. The two-way diff transfer is also very nice, and the way it handles binaries makes me confident storing binaries in a repository. I only have a handful of developers hitting my server, but I haven't heard of any scalability problems from other SVN projects. If it came to a vote, I'd say switch to SVN. Dave
Hello, I tried to post this one to the boost.users newsgroup, but I did not succeed: " Hello, According to the docs and the source, boost::apply_visitor has two overloads now: template<typename Visitor, typename Variant> typename Visitor::result_type apply_visitor(Visitor & visitor, Variant & operand); template<typename Visitor, typename Variant> typename Visitor::result_type apply_visitor(const Visitor & visitor, Variant & operand); None of them is capable of taking a Variant instance by const reference, only by reference. One can certainly find workarounds for it, but that is not very simple, see for example an attempt trying to remove constness using const_cast: typedef boost::variant<int, std::string> MyVariant; boost::apply_visitor(MyVisitor(), const_cast<MyVariant&>(MyVariant()); This does not work either due to rvalue/lvalue issues. One can write some wrapper functions of course, but it is inconvenient. My questions are: is this the product of intentional design? If it is, what are the reasons for not allowing to pass variant by const references? If it is not, what should be the most elegant way to visit variants through const references? Sincerely Sandor Szalacsi " -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.8.4 - Release Date: 2005.02.01.
"Brian Braatz" <brianb@rmtg.com> writes:
My Opinion: I like SVN, but we have not completely switched over to it For Boost, the redundant servers from sourceforge is a compelling reason to stay cvs. I am not aware if you can get the same thing from sourceforge with svn.
I've said from the beginning that hosting would move to OSL. They have (or can get) all the redundancy and backup that we need. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (3)
-
Brian Braatz -
David Abrahams -
David B. Held -
Szalacsi Sandor