RE: [boost] Re: Was [RE: 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 David B. Held Sent: Wednesday, February 02, 2005 3:50 PM To: boost@lists.boost.org Subject: [boost] Re: Was [RE: Moving from CVS to Subversion?] Now is "Subversion experiences from the field"
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
[Brian Braatz] If boost goes SVN though, who runs the servers? Does sourceforge do this? We have had more admin with SVN than with CVS. (the Berkley db needs tending to from time to time)
On Wed, 2 Feb 2005 22:26:07 -0700, Brian Braatz wrote
[Brian Braatz] If boost goes SVN though, who runs the servers? Does sourceforge do this?
Nope -- SF doesn't host subversion yet. Indiana U. Open Systems Lab (OSL) has volunteered.
We have had more admin with SVN than with CVS. (the Berkley db needs tending to from time to time)
From my reading it looks like the new FSFS backend might be a bit better about that, but maybe a bit slower overall. The OSL folks said earlier in this thread that they are already running some subversion repositories -- don't know which backend they are used to...
Jeff
[Brian Braatz] If boost goes SVN though, who runs the servers? Does sourceforge do this? We have had more admin with SVN than with CVS. (the Berkley db needs tending to from time to time)
Well, I think the fsfs back end should work just fine, and we will probably have to set it up ourselves. If someone else offers server space, I will offer to set up the SVN server. Can't we get a corporate sponsor or someone to donate space? Dave
On Wed, 02 Feb 2005 23:49:33 -0600, David B. Held wrote
[Brian Braatz] If boost goes SVN though, who runs the servers? Does sourceforge do this? We have had more admin with SVN than with CVS. (the Berkley db needs tending to from time to time)
Well, I think the fsfs back end should work just fine, and we will probably have to set it up ourselves. If someone else offers server space, I will offer to set up the SVN server. Can't we get a corporate sponsor or someone to donate space?
Please read the start of the thread about the potential of OSL to host for us. http://thread.gmane.org/gmane.comp.lib.boost.devel/116994 http://thread.gmane.org/gmane.comp.lib.boost.devel/116994 Jeff
"Brian Braatz" <brianb@rmtg.com> writes:
[Brian Braatz] If boost goes SVN though, who runs the servers? Does sourceforge do this?
no OSL (http://osl.iu.edu) -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> wrote:
"Brian Braatz" <brianb@rmtg.com> writes:
[Brian Braatz] If boost goes SVN though, who runs the servers? Does sourceforge do this?
no OSL (http://osl.iu.edu)
One possibility would be to have OSL just host a CVS server, and see whether that clears up most of the problems. Cheers, Walter Landry wlandry@ucsd.edu
Walter Landry wrote:
David Abrahams <dave@boost-consulting.com> wrote:
[...] no OSL (http://osl.iu.edu)
One possibility would be to have OSL just host a CVS server, and see whether that clears up most of the problems.
I think passing up an opportunity to migrate to SVN would be contrary to the spirit of Boost being a cutting-edge community. It's not like it's a gratuitous switch with no obvious benefits. I think anybody who's taken a look at SVN can see that there are definitely improvements over CVS. To be honest with you, taking a look at what is available in the Java world, I have to say that the C++ community is working in the Stone Age still. It needs every leg up it can get. Dave
On Thu, 03 Feb 2005 22:22:22 -0600, David B. Held wrote
Walter Landry wrote:
David Abrahams <dave@boost-consulting.com> wrote:
[...] no OSL (http://osl.iu.edu)
One possibility would be to have OSL just host a CVS server, and see whether that clears up most of the problems.
It's an interesting suggestion to try out CVS at OSL -- it would carry far less risk and could serve as a stepping stone to SVN at OSL. It would be very easy to go back if it went wrong. It also means we wouldn't be violating the all important 'change one thing at a time' principle.
I think passing up an opportunity to migrate to SVN would be contrary to the spirit of Boost being a cutting-edge community.
Spirit can be sapped by a lack of volunteers with too much work...
It's not like it's a gratuitous switch with no obvious benefits. I think anybody who's taken a look at SVN can see that there are definitely improvements over CVS.
While I agree there are likely benefits, it doesn't come without significant cost and risk that isn't really focused on our main mission (see my other posts). We have 86 'committers' listed on the SF page and we've really only heard the opinions of a few -- mostly me and Dave. I'm certain that it's time for me to shut up now and listen to others ;-) Jeff
Jeff Garland wrote:
On Thu, 03 Feb 2005 22:22:22 -0600, David B. Held wrote
Walter Landry wrote:
David Abrahams <dave@boost-consulting.com> wrote:
[...] no OSL (http://osl.iu.edu)
One possibility would be to have OSL just host a CVS server,
and see whether that clears up most of the problems.
It's an interesting suggestion to try out CVS at OSL -- it would carry far less risk and could serve as a stepping stone to SVN at OSL. It would be very easy to go back if it went wrong. It also means we wouldn't be violating the all important 'change one thing at a time' principle.
Along that same line of not changing more than one thing.. Perhaps SF would be open to experimenting with SVN support. Perhaps it's been long enough for SF to consider taking a request from a few projects to use SVN. It doesn't hurt to ask them if they would provide the experimental service just to see what all our options are.
We have 86 'committers' listed on the SF page and we've really only heard the opinions of a few -- mostly me and Dave. I'm certain that it's time for me to shut up now and listen to others ;-)
I've used a variety of version control systems, CVS, SVN, SourceSafe, Perforce, etc. and even written my own. The current SF provided CVS doesn't cause real problems for me. I haven't had a lock problem in more than a year and I do full checkouts daily. SF is on the slow side when it comes to doing those updates though. My experience with SVN has not been all that pleasant but perhaps it's a result of only using the command line, maybe the GUIs out there fare better. 1. Obtaining information about the repository without doing a checkout of every branch, tag, etc. is horribly painful. The history/log facility is almost useless. For example I don't think theres way to find out in what branches/tags a particular file revision is part of, other than getting the complete repository and doing a file find.. yuk. 2. Conflict resolution when doing a merge is basically unworkable. Like CVS it decorates the working copy with "<<"/">>" comments, and copies the previous version. But the conflict resolution algorithm it uses makes worse, IMO, choices than the CVS equivalent. Often resulting in larger conflicts than CVS. 3. The lack of in place branching makes many things harder, and the possible equivalent of "svn copy"+"svn switch" is very difficult to manage. This discourages the use of small short lived branches useful for experimental code changes. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
"Rene Rivera" <grafik.list@redshift-software.com> wrote in message news:420311B9.7090208@redshift-software.com... [snip]
I've used a variety of version control systems, CVS, SVN, SourceSafe, Perforce, etc. and even written my own.
What about Perforce then? Out of curiosity, what's your experience with it (compared to CVS/SVN)? // Johan
Rene Rivera <grafik.list@redshift-software.com> writes:
My experience with SVN has not been all that pleasant but perhaps it's a result of only using the command line, maybe the GUIs out there fare better.
Your reports below are certainly worrisome
1. Obtaining information about the repository without doing a checkout of every branch, tag, etc. is horribly painful. The history/log facility is almost useless. For example I don't think theres way to find out in what branches/tags a particular file revision is part of, other than getting the complete repository and doing a file find.. yuk.
There are various filter programs for post-processing SVN log output, but I haven't looked at or used any of them, and frankly don't know if any address this issue. http://svn.haxx.se/users/archive-2004-07/1602.shtml seems to indicate that the SVN people think it was worth trading that capability away to gain some others. Now that I think of it, I've never wanted to see every branch that a file is part of. Tracing back through a single branch is usually all I'm interested in. There is a tool called svnmerge that, if we used it for merging, should make it possible to look backwards through merge points as well. Or so I think. http://svn.haxx.se/users/archive-2004-12/0409.shtml
2. Conflict resolution when doing a merge is basically unworkable. Like CVS it decorates the working copy with "<<"/">>" comments, and copies the previous version. But the conflict resolution algorithm it uses makes worse, IMO, choices than the CVS equivalent.
Seriously?? I've never heard that before, but if so, that's just dumb. It's not as though the CVS algorithm isn't open source!
Often resulting in larger conflicts than CVS.
3. The lack of in place branching makes many things harder
Like what?
and the possible equivalent of "svn copy"+"svn switch" is very difficult to manage.
Why?
This discourages the use of small short lived branches useful for experimental code changes.
Hmm. I'm getting nervous. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Rene Rivera wrote:
[...] My experience with SVN has not been all that pleasant but perhaps it's a result of only using the command line, maybe the GUIs out there fare better.
Perhaps you should try TortoiseSVN. It's fairly slick and makes things decently intuitive. But really, you should try Eclipse. Unfortunately, the easiest type of project for Eclipse is Java. But there's no reason someone couldn't write nice C++ plugins for Eclipse (and I rather think someone should). If you could see how Eclipse integrates with SVN, you would probably agree that most if not all of your problems go away.
1. Obtaining information about the repository without doing a checkout of every branch, tag, etc. is horribly painful. The history/log facility is almost useless. For example I don't think theres way to find out in what branches/tags a particular file revision is part of, other than getting the complete repository and doing a file find.. yuk.
Hmm...not sure why you would need to do this, but I would be curious to see what they say on the mailing list. On the other hand, A) most people who need this information will probably already have the repository checked out, right? B) This doesn't seem like a very common operation. Probably not something that the average coder will need to be doing regularly. On the other hand, the things that the average coder will be doing often are mostly done better by SVN (like 2-way diffs, local caching of revisions for fast local history, more complete tracking of repository changes, like file renames, directory restructuring, etc.). As far as using the history for normal type tasks, it seemed perfectly reasonable to me, and not too dissimilar from other VCSes.
2. Conflict resolution when doing a merge is basically unworkable. Like CVS it decorates the working copy with "<<"/">>" comments, and copies the previous version. But the conflict resolution algorithm it uses makes worse, IMO, choices than the CVS equivalent. Often resulting in larger conflicts than CVS.
I can't speak to conflict resolution by hand. But in Eclipse, it is much much easier than the various conflict resolution tools I've used for CVS. The different lines of code are connected by a line that stretches as you scroll the different windows, making it very easy to spot the changes and see how they fit in the overall structure. Copying changes one way or the other is just a simple mouse click. I really don't see how it could be any simpler without the IDE reading your mind.
3. The lack of in place branching makes many things harder, and the possible equivalent of "svn copy"+"svn switch" is very difficult to manage. This discourages the use of small short lived branches useful for experimental code changes.
Actually, SVN makes it a point that branches are cheap exactly because they do a shallow copy, and that you should make as many branches as you like. It may be difficult to manage from the command line, but again, I don't know, because branching and switching in Eclipse is both trivial and utterly painless. The only trick I had was merging changes from one branch to another, but that's just because I don't do that very often, so it's not very intuitive for me. I haven't tried it from TortoiseSVN, though, so it might be more complicated there. It really is unfortunate that there isn't a good C++ plugin for Eclipse. You would wonder how you ever coded without it. Dave
On Feb 4, 2005, at 1:10 AM, Rene Rivera wrote:
My experience with SVN has not been all that pleasant but perhaps it's a result of only using the command line, maybe the GUIs out there fare better.
1. Obtaining information about the repository without doing a checkout of every branch, tag, etc. is horribly painful. The history/log facility is almost useless. For example I don't think theres way to find out in what branches/tags a particular file revision is part of, other than getting the complete repository and doing a file find.. yuk. [snip] 3. The lack of in place branching makes many things harder, and the possible equivalent of "svn copy"+"svn switch" is very difficult to manage. This discourages the use of small short lived branches useful for experimental code changes.
Reading about Mono's switch to svn made me wonder if some of these problems are because we're trying to use our cvs tricks with svn, when those tricks have only become habit to get around cvs's limitations. For instance, what do you mean by a "small" branch? It made me think of the graph_devel branch, where I only branched the boost/graph and libs/graph subdirectories [1]. I'd then test my branch be switching over those two directories (only) within a full checkout of the trunk, and develop that way. It's a bit of a strange model, because I never had a full branch, just a few files, and I've weave the two together. The "svn way" to do this would be to create a whole branch (a trivial operation: copies are cheap), which would be entirely separate from the main branch. Interestingly, I did find that I had to switch between the two multiple times, such that it would have been nice to have two separate branches [1]. [1] The reasons I tagged only those two directories are CVS limitations. Branching, checkout, and update all take a really long time with CVS (especially the first one), so I wanted to branch and change as little as possible in my tree. [2] I could have faked two separate, full branches by copying the top-level "boost" directory, renaming one to include the branch name, and updating with "-A" in the "head" branch but not the other. Subversion's workflow is different from CVS's. Whenever we say that Subversion can't do something well that CVS can, we should step back from the task to determine if that's really what we want. We wouldn't complain that C++ compiler X couldn't emulate "typeof" properly when it gives us "decltype", I think Subversion is in some ways harmed because it's touted as "a better cvs" and not "a version control system with a similar interface to cvs". I'm sure it'll have plenty of failings without us pushing it :) Doug
Douglas Gregor wrote:
Reading about Mono's switch to svn made me wonder if some of these problems are because we're trying to use our cvs tricks with svn, when those tricks have only become habit to get around cvs's limitations.
Alan Gutierrez wrote:
I'm not sure where to chime in, but I was just attempting to check out one of the Jakarta Commons sub-projects.
Their directory structure is such that, if you want to checkout all of commons, you cant simply checkout trunk/commons, because you'll checkout every branch, ever.
It looks like this:
/huge-library-project /library-1 /trunk /BRANCH_1 /BRANCH_1_1 /BRANCH_1_2 ... /library-2 /trunk /RELEASE_2_0 /RC_2_0 /RC_2_1 ... ...
Might be easier to manage a specific library, but it's hard on the non-commiter that want's to build from source control.
In any case, I hope you'll consider carefully, the project structure when you move away from the tag based system in CVS.
SVN accomodates this structure quite nicely. In the spirit of considering the project structure carefully, here's a few thoughts. Assume that you have your libraries broken up as in the jakarta example above. boost would look something like this: /boost /boost /shared_ptr /trunk /branches/v1.0 /branches/v1.1 /type_traits /trunk /branches/v1.0 /branches/some_other_branch /libs /shared_ptr /trunk /branches/v1.0 /type_traits /trunk /branches/v1.0 /branches/some_other_branch /tools /trunk /branches/v1.0 Now that kind of looks like a nightmare, but svn makes it pretty easy to handle. A checkout of the trunk should assemble the trunks of each sublibrary locally in such a way that immediately after the checkout, you're ready to bjam without additional work. Named releases should do something similar, but with various releases of various sublibraries. Subversion supports this with "externals", simply a mapping from local directory to some other directory back in the repository, such that when you check out the directory containing the externals, svn automatically does the specified checkouts. So the trunk externals for the test case would be: boost/shared_ptr http://svn.boost.org/boost/boost/shared_ptr/trunk libs/shared_ptr http://svn.boost.org/boost/libs/shared_ptr/trunk boost/type_traits http://svn.boost.org/boost/boost/type_traits/trunk libs/type_traits http://svn.boost.org/boost/libs/type_traits/trunk tools http://svn.boost.org/boost/tools/trunk which would leave you looking at something that was pretty close to what boost currently looks like. To see a small test case, click around how things are organized at http://svn.resophonic.com/otherboost. You won't be able to see the externals properties in a web browser, but if you check out the trunk svn co http://svn.resophonic.com/otherboost/trunk you'll see that your directories get populated with the trunks of the sublibraries. run "svn propedit svn:externals ." to see the actual list. in any of those sublibraries you can switch from version to version by changing the list you see in propedit, or by cding to the directory and using "svn switch". Can't see exactly how this would have affected Doug Gregor's life in the graph_devel case he mentioned. If you "svn co" the other directories, like http://svn.resophonic.com/otherboost/v1.0, you'll see that the branched versions of the sublibraries get pulled down instead of the trunks. http://svn.resophonic.com/otherboost/shared_ptr-only links in only the shared_ptr, a subdistribution example. I mentioned this in a previous thread, since I now have an example together and the topic of doing things differently than CVS has come up since then, I wanted to reintroduce the idea. Subdistributions of boost would be easy to assemble: leave out certain libraries. In CVS, if somebody commits something to the head of their library that breaks stuff boost-wide, in order to fix the head, you have to check out the old version, merge it back in to the head and commit it, perhaps after branching off the changes that broke things, if they are to be reintroduced later (I'm thinking of the recent boost.test stuff...); With this externals scheme, one just changes a couple lines in the trunk's svn:externals properties to refer to an older version of the problematic sublibrary. There is a certian difference in visibility here with respect to what branches exist in the repository and how many concurrent "threads" of development there actually are: they are laid out for you in each sublibrary. By contrast, The "head" isn't just all the source that happens to be associated with some common identifier in source control, it is instead the collection of branches of individual sublibraries that work the best together and have collectively the highest revision number. Additional levels of abstraction, all that. Just FWIW troy d. straszheim
troy d. straszheim wrote:
SVN accomodates this structure quite nicely. In the spirit of considering the project structure carefully, here's a few thoughts. Assume that you have your libraries broken up as in the jakarta example above. boost would look something like this:
/boost /boost /shared_ptr /trunk /branches/v1.0 /branches/v1.1 /type_traits /trunk /branches/v1.0 /branches/some_other_branch /libs /shared_ptr /trunk /branches/v1.0 /type_traits /trunk /branches/v1.0 /branches/some_other_branch /tools /trunk /branches/v1.0
Now that kind of looks like a nightmare, but svn makes it pretty easy to handle. A checkout of the trunk should assemble the trunks of each sublibrary locally in such a way that immediately after the checkout, you're ready to bjam without additional work. Named releases should do something similar, but with various releases of various sublibraries.
I think this is a good idea, but the problem is that a lot of libraries have code in the boost directory (such as boost/shared_ptr.hpp). They could possibly be changed to just include the implementation from a subdirectory. Would this be worth it? I actually think that might be a good idea anyway. This would be very nice for Spirit, which has two active versions. Daniel
* Daniel James <daniel@calamity.org.uk> [2005-02-06 05:01]:
troy d. straszheim wrote:
SVN accomodates this structure quite nicely. In the spirit of considering the project structure carefully, here's a few thoughts. Assume that you have your libraries broken up as in the jakarta example above. boost would look something like this:
/boost /boost /shared_ptr /trunk /branches/v1.0 /branches/v1.1 /type_traits /trunk /branches/v1.0 /branches/some_other_branch /libs /shared_ptr /trunk /branches/v1.0 /type_traits /trunk /branches/v1.0 /branches/some_other_branch /tools /trunk /branches/v1.0
Now that kind of looks like a nightmare, but svn makes it pretty easy to handle. A checkout of the trunk should assemble the trunks of each sublibrary locally in such a way that immediately after the checkout, you're ready to bjam without additional work. Named releases should do something similar, but with various releases of various sublibraries.
I think this is a good idea, but the problem is that a lot of libraries have code in the boost directory (such as boost/shared_ptr.hpp). They could possibly be changed to just include the implementation from a subdirectory. Would this be worth it? I actually think that might be a good idea anyway.
This would be very nice for Spirit, which has two active versions.
How do you propose a person asssembles a boost checkout? Currently you simply run a single command to grab all of boost. cvs -d [pserver] co [module] Everything is pulled. With the above, would I not have to checkout... svn checkout http://foo.com/boost/shared_ptr/trunk shared_ptr svn checkout http://foo.com/boost/type_traits/trunk type_traits ... and so on, for every sub-library in boost? -- Alan Gutierrez - alan@engrm.com
Alan Gutierrez wrote:
How do you propose a person asssembles a boost checkout?
Currently you simply run a single command to grab all of boost.
cvs -d [pserver] co [module]
Everything is pulled.
With the above, would I not have to checkout...
svn checkout http://foo.com/boost/shared_ptr/trunk shared_ptr svn checkout http://foo.com/boost/type_traits/trunk type_traits
... and so on, for every sub-library in boost?
No, I snipped the part of Troy's email that explained that. From http://lists.boost.org/MailArchives/boost/msg78400.php troy d. straszheim wrote:
To see a small test case, click around how things are organized at http://svn.resophonic.com/otherboost. You won't be able to see the externals properties in a web browser, but if you check out the trunk
svn co http://svn.resophonic.com/otherboost/trunk
you'll see that your directories get populated with the trunks of the sublibraries.
Setting it up will probably be a pain. But using it should be easy? Daniel
How do you propose a person asssembles a boost checkout?
Currently you simply run a single command to grab all of boost.
cvs -d [pserver] co [module]
Everything is pulled.
With the above, would I not have to checkout...
svn checkout http://foo.com/boost/shared_ptr/trunk shared_ptr svn checkout http://foo.com/boost/type_traits/trunk type_traits
... and so on, for every sub-library in boost?
svn checkout http://foo.com/boost would this suffice?
At Thursday 2005-02-03 21:47, you wrote:
On Thu, 03 Feb 2005 22:22:22 -0600, David B. Held wrote
Walter Landry wrote:
David Abrahams <dave@boost-consulting.com> wrote:
[...] no OSL (http://osl.iu.edu)
One possibility would be to have OSL just host a CVS server, and see whether that clears up most of the problems.
It's an interesting suggestion to try out CVS at OSL -- it would carry far less risk and could serve as a stepping stone to SVN at OSL. It would be very easy to go back if it went wrong. It also means we wouldn't be violating the all important 'change one thing at a time' principle.
I think passing up an opportunity to migrate to SVN would be contrary to the spirit of Boost being a cutting-edge community.
Spirit can be sapped by a lack of volunteers with too much work...
It's not like it's a gratuitous switch with no obvious benefits. I think anybody who's taken a look at SVN can see that there are definitely improvements over CVS.
While I agree there are likely benefits, it doesn't come without significant cost and risk that isn't really focused on our main mission (see my other posts).
We have 86 'committers' listed on the SF page and we've really only heard the opinions of a few -- mostly me and Dave. I'm certain that it's time for me to shut up now and listen to others ;-)
ok, let's add one more. Nobody seems to have considered CVSNT It's actively being worked on. Everything that used to work in CVS still does There are new features also that make it attractive (not the least of which is a lock server instead of the lock files) and a (very hopefully soon) fully functional "rename". some enhancements in the handling of merges would be useful to Boost. http://www.cvsnt.com/cvspro/
Jeff
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
"Victor A. Wagner Jr." <vawjr@rudbek.com> writes:
ok, let's add one more. Nobody seems to have considered CVSNT It's actively being worked on. Everything that used to work in CVS still does There are new features also that make it attractive (not the least of which is a lock server instead of the lock files) and a (very hopefully soon) fully functional "rename". some enhancements in the handling of merges would be useful to Boost. http://www.cvsnt.com/cvspro/
And despite being called "CVSNT", it still runs fine on Linux servers. My experience with using it has been good. It's certainly a huge improvement over plain CVS. Anthony -- Anthony Williams Software Developer
Jeff Garland wrote:
One possibility would be to have OSL just host a CVS server, and see whether that clears up most of the problems.
It's an interesting suggestion to try out CVS at OSL -- it would carry far less risk and could serve as a stepping stone to SVN at OSL. It would be very easy to go back if it went wrong.
I doubt that CVS at OSL will bring more benefit that CVS at SF. We might get more performance, but SF's performance is not so bad for me.
It's not like it's a gratuitous switch with no obvious benefits. I think anybody who's taken a look at SVN can see that there are definitely improvements over CVS.
While I agree there are likely benefits, it doesn't come without significant cost and risk that isn't really focused on our main mission (see my other posts).
We have 86 'committers' listed on the SF page and we've really only heard the opinions of a few -- mostly me and Dave. I'm certain that it's time for me to shut up now and listen to others ;-)
I'd like Subversion, for sure. When we wanted move Boost.Build V1 and V2 to different directories, this was nontrivial -- including writing some script and passing a request to SF staff. And I'd like to move some more files... I think the only problematic part could be CVS -> SVN conversion script. If the scripts runs OK and we verify the converted repository, there should be no problems. I was using Subversion for more that year (Apache + Berkeley DB) and there were no problems. - Volodya
participants (8)
-
Alan Gutierrez -
Anthony Williams -
Brian Braatz -
Daniel James -
David Abrahams -
David B. Held -
Douglas Gregor -
Jeff Garland -
Johan Nilsson -
Mathew Robertson -
Rene Rivera -
troy d. straszheim -
Victor A. Wagner Jr. -
Vladimir Prus -
Walter Landry