Checking out latest Boost lock problem
Attempting to check out the latest Boost I am being stopped by: cvs checkout: [23:53:01] waiting for agurtovoy's lock in /cvsroot/boost/boost/libs/utility/doc
Edward Diener wrote:
Attempting to check out the latest Boost I am being stopped by:
cvs checkout: [23:53:01] waiting for agurtovoy's lock in /cvsroot/boost/boost/libs/utility/doc
I got this last night as well, and now I get: cvs update: [11:54:03] waiting for martin_wille's lock in /cvsroot/boost/boost/tools/build/v2/test/m1-03 CVS has now thwarted my last four attempts to check out. I wonder if "subversion" has been considered as an alternative? IMHO it is well worth playing with. I have used it with excellent results, the subversion team has preserved the interface of CVS and fixed many issues that I had come to accept as the facts of life (takes forever to update/diff, can't version directory structure, lock problems...) Maybe I'm the only one feeling CVS pain, but if there were interest I could easily import boost into a publicly availably subversion repository for people to play with. -- troy d. straszheim
troy d. straszheim wrote:
Edward Diener wrote:
Attempting to check out the latest Boost I am being stopped by:
cvs checkout: [23:53:01] waiting for agurtovoy's lock in /cvsroot/boost/boost/libs/utility/doc
I got this last night as well, and now I get:
cvs update: [11:54:03] waiting for martin_wille's lock in /cvsroot/boost/boost/tools/build/v2/test/m1-03
CVS has now thwarted my last four attempts to check out. I wonder if "subversion" has been considered as an alternative? IMHO it is well worth playing with. I have used it with excellent results, the subversion team has preserved the interface of CVS and fixed many issues that I had come to accept as the facts of life (takes forever to update/diff, can't version directory structure, lock problems...) Maybe I'm the only one feeling CVS pain, but if there were interest I could easily import boost into a publicly availably subversion repository for people to play with.
I am all for Subversion also, since I have used it successfully in professional work and am doing so now. It is irritating that one is not able to get the latest Boost because of these lock problems. However that may not be a CVS versus Subversion issue. No doubt a CVS expert will tell me whether it is or not.
On Sun, 30 Jan 2005 12:15:18 -0500, Edward Diener wrote
troy d. straszheim wrote:
Edward Diener wrote:
Attempting to check out the latest Boost I am being stopped by:
cvs checkout: [23:53:01] waiting for agurtovoy's lock in /cvsroot/boost/boost/libs/utility/doc
I got this last night as well, and now I get:
cvs update: [11:54:03] waiting for martin_wille's lock in /cvsroot/boost/boost/tools/build/v2/test/m1-03
CVS has now thwarted my last four attempts to check out. I wonder if "subversion" has been considered as an alternative? IMHO it is well worth playing with. I have used it with excellent results, the subversion team has preserved the interface of CVS and fixed many issues that I had come to accept as the facts of life (takes forever to update/diff, can't version directory structure, lock problems...) Maybe I'm the only one feeling CVS pain, but if there were interest I could easily import boost into a publicly availably subversion repository for people to play with.
I am all for Subversion also, since I have used it successfully in professional work and am doing so now. It is irritating that one is not able to get the latest Boost because of these lock problems. However that may not be a CVS versus Subversion issue. No doubt a CVS expert will tell me whether it is or not.
Subversion isn't a realistic choice at the moment unless we are going to move away from sourceforge for repository hosting. Quoting from the docs at: http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1#alternateversioning CVS is not the only version control system available in the world. One (very promising) version control system currently under development is Subversion. Subversion, an Open Source version control system (like CVS), has been designed to solve a number of the design flaws found in CVS. At this time, Subversion is still under heavy development and has not yet reached the level of stability and maturity needed to provide production-grade Subversion services from SourceForge.net. The SourceForge.net team is continuing to evaluate the progress of the Subversion development process and will consider providing Subversion services once a suitable level of maturity has been reached. Jeff
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
On Sun, 30 Jan 2005 12:15:18 -0500, Edward Diener wrote
troy d. straszheim wrote:
I am all for Subversion also, since I have used it successfully in professional work and am doing so now. It is irritating that one is not able to get the latest Boost because of these lock problems. However that may not be a CVS versus Subversion issue. No doubt a CVS expert will tell me whether it is or not.
Yes, we have run to the edge of CVS's capabilities. How long does it take you to update?
Subversion isn't a realistic choice at the moment unless we are going to move away from sourceforge for repository hosting.
Actually the moderators have been discussing doing just that. OSL is going to provide us with SVN support. The mods just agreed that I would announce the idea here so people can get used to it, and so we can make the move when the resources become available (about a month away). Here's a short SVN Q&A:
* What URL should I look at for more Subversion information?
* Will nightly tarballs be available?
That's up to whoever administrates the system, but it seems super-likely that we can get OSL to do it.
* Who will administrate? Are they experienced with Subversion?
OSL will administer the hardware; they have several projects using Subversion at OSL, at least one of which is comparable in size to Boost. Hopefully their sysadmins will grant the boost moderators full admin privileges over the SVN repository. Doug Gregor (who is at OSL) says: "I think we can do this. Subversion doesn't seem to have quite as many issues as CVS, so we shouldn't need help as often, but the sysadmins will be responsive and there are several Boosters on-site."
* Will Web access similar to ViewCVS be available?
I'm pretty sure we can make it available; see http://geekswithblogs.net/flanakin/articles/CompareSubversionWebTools.aspx
* Why are you suggesting Subversion rather other CVS competitors?
It's designed to be the successor to CVS; it's open source. Some of us have experience with it.
* Are both command line and GUI clients available for various operating systems?
Yeah; see http://rapidsvn.tigris.org/
* Can any boosters with hands-on Subversion experience comment on usefulness, reliability, etc?
Yes; I can, or any of the OSL guys.
* Should we move boost-sandbox first to gain experience?
Interesting idea.
* Will Rene's vault software still work?
AFAIK that's independent of version control, so there's no reason it shouldn't. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Sun, 30 Jan 2005 23:33:45 -0500, David Abrahams wrote
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
On Sun, 30 Jan 2005 12:15:18 -0500, Edward Diener wrote
troy d. straszheim wrote:
I am all for Subversion also, since I have used it successfully in professional work and am doing so now. It is irritating that one is not able to get the latest Boost because of these lock problems. However that may not be a CVS versus Subversion issue. No doubt a CVS expert will tell me whether it is or not.
Yes, we have run to the edge of CVS's capabilities. How long does it take you to update?
Honestly, I don't know -- I don't update that frequently (maybe every few weeks) so updates aren't a big deal for me. I'm not going to speak out against converting -- I recognize the limits of CVS and understand that others may be constrained by them now. My only caution is that we need to be methodical and ensure that boost development isn't ground to a halt -- everyone is going to have to invest time to make any conversion happen.
Subversion isn't a realistic choice at the moment unless we are going to move away from sourceforge for repository hosting.
Actually the moderators have been discussing doing just that. OSL is going to provide us with SVN support. The mods just agreed that I would announce the idea here so people can get used to it, and so we can make the move when the resources become available (about a month away).
I assume OSL is the Open Systems Lab at Indiana Univ.
OSL will administer the hardware; they have several projects using Subversion at OSL, at least one of which is comparable in size to Boost. Hopefully their sysadmins will grant the boost moderators full admin privileges over the SVN repository. Doug Gregor (who is at OSL) says:
"I think we can do this. Subversion doesn't seem to have quite as many issues as CVS, so we shouldn't need help as often, but the sysadmins will be responsive and there are several Boosters on-site."
I have my doubts that they are comparible in size w.r.t number of users. Are these internal projects or external projects? Please don't take this next statement wrong -- I appreciate greatly the contribution of OSL folks and resources -- just trying to make sure before we jump off of something that is basically working from my view. Since we moved the mailing lists there have been issues that never got resolved -- specifically, the archive seems to lose messages or get stuck and posts take up to 30 minutes to be processed and reflected back. That was a clear step down from Yahoo groups which was basically immediate response and never lost a message. Again, I'm not complaining or blaming -- I suspect that the admins at OSL are just dealing with buggy / non-performant mailing list software. But the question is, how can we ensure we don't have a similar service degredation issues with a conversion to subversion? We can survive the issues with the mailing list easier than we can the repository -- although both of the mailing list problems are reasonably serious.
* Should we move boost-sandbox first to gain experience?
Interesting idea.
I think we should use the actual boost source tree. The sandbox doesn't have the same scale or activity. I'm not sure how to really test it short of people actually developing against it and then somehow taking finished results back to CVS during the transition. Maybe we need to have a coordinated test where we all agree to pull down the whole repository at a certain time -- just to make sure the machines/network/software is really up to the task? Maybe there are other tests we should do before jumping ship? One last question, how much of our version history will we lose? Will be still be able to pull the 1.32 branch out of subversion or will we have to go back to the legacy repository to see this? There are tools for conversion, but there are lots of options. Someone will need to take a long look at this, but if we convert I'd like to see us convert for good and not lose history in the process. See http://cvs2svn.tigris.org/cvs2svn.html for more. Jeff ps: The lock is still stuck -- I was running an update test and got the problem....
[DongInn, I have Cc'd you because there are two problems with the Boost mailing list cited here] [Doug G., you need to answer a question below] "Jeff Garland" <jeff@crystalclearsoftware.com> writes:
On Sun, 30 Jan 2005 23:33:45 -0500, David Abrahams wrote
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
On Sun, 30 Jan 2005 12:15:18 -0500, Edward Diener wrote
troy d. straszheim wrote:
I am all for Subversion also, since I have used it successfully in professional work and am doing so now. It is irritating that one is not able to get the latest Boost because of these lock problems. However that may not be a CVS versus Subversion issue. No doubt a CVS expert will tell me whether it is or not.
Yes, we have run to the edge of CVS's capabilities. How long does it take you to update?
Honestly, I don't know -- I don't update that frequently (maybe every few weeks) so updates aren't a big deal for me. I'm not going to speak out against converting -- I recognize the limits of CVS and understand that others may be constrained by them now. My only caution is that we need to be methodical and ensure that boost development isn't ground to a halt -- everyone is going to have to invest time to make any conversion happen.
I'm all for being methodical, but honestly if boost development ground to a halt for a couple of days I think we'd survive.
Subversion isn't a realistic choice at the moment unless we are going to move away from sourceforge for repository hosting.
Actually the moderators have been discussing doing just that. OSL is going to provide us with SVN support. The mods just agreed that I would announce the idea here so people can get used to it, and so we can make the move when the resources become available (about a month away).
I assume OSL is the Open Systems Lab at Indiana Univ.
Yes.
OSL will administer the hardware; they have several projects using Subversion at OSL, at least one of which is comparable in size to Boost. Hopefully their sysadmins will grant the boost moderators full admin privileges over the SVN repository. Doug Gregor (who is at OSL) says:
"I think we can do this. Subversion doesn't seem to have quite as many issues as CVS, so we shouldn't need help as often, but the sysadmins will be responsive and there are several Boosters on-site."
I have my doubts that they are comparible in size w.r.t number of users. Are these internal projects or external projects?
I can't answer this one... Doug?
Please don't take this next statement wrong -- I appreciate greatly the contribution of OSL folks and resources -- just trying to make sure before we jump off of something that is basically working from my view. Since we moved the mailing lists there have been issues that never got resolved -- specifically, the archive seems to lose messages or get stuck
That archiving software ** sucks **. Subversion is, in my experience, much better engineered.
and posts take up to 30 minutes to be processed and reflected back.
Is that still the case?
That was a clear step down from Yahoo groups which was basically immediate response and never lost a message. Again, I'm not complaining or blaming -- I suspect that the admins at OSL are just dealing with buggy / non-performant mailing list software. But the question is, how can we ensure we don't have a similar service degredation issues with a conversion to subversion? We can survive the issues with the mailing list easier than we can the repository -- although both of the mailing list problems are reasonably serious.
* Should we move boost-sandbox first to gain experience?
Interesting idea.
I think we should use the actual boost source tree. The sandbox doesn't have the same scale or activity. I'm not sure how to really test it short of people actually developing against it and then somehow taking finished results back to CVS during the transition.
Maybe we need to have a coordinated test where we all agree to pull down the whole repository at a certain time -- just to make sure the machines/network/software is really up to the task?
That's a bad test IMO. If we all hit CVS at the same time, how good do you think the response time will be?
Maybe there are other tests we should do before jumping ship?
Name 'em and we can consider them. Otherwise it's just FUD.
One last question, how much of our version history will we lose?
None.
Will be still be able to pull the 1.32 branch out of subversion
Yes.
or will we have to go back to the legacy repository to see this? There are tools for conversion, but there are lots of options. Someone will need to take a long look at this, but if we convert I'd like to see us convert for good and not lose history in the process. See http://cvs2svn.tigris.org/cvs2svn.html for more.
OSL has already done several conversions; it's not that complicated.
Jeff
ps: The lock is still stuck -- I was running an update test and got the problem....
You shouild report it to the SourceForge admins and ask them to clear it. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Jan 31, 2005, at 11:17 AM, David Abrahams wrote:
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
I have my doubts that they are comparible in size w.r.t number of users. Are these internal projects or external projects?
I can't answer this one... Doug?
These are internal projects, mainly, so they have fewer users than Boost. There are some big users of subversion listed on their propaganda page: http://subversion.tigris.org/propaganda.html I think we can be reasonably assured that the Subversion software can handle the Boost repository. Your second question was whether OSL has the resources and capabilities to manage such a repository. I can't give you a definitive "yes" on that without having tried it. However, I can say that Boost is important at OSL, so turnaround time on problems should be much better than with Sourceforge, where we're just one of 94,673 projects. And since we use subversion for other projects, a broken Boost repository probably means a broken repository for anything else; we're not going to allow work to grind to a halt for the whole lab. Doug
Doug Gregor <dgregor <at> cs.indiana.edu> writes:
On Jan 31, 2005, at 11:17 AM, David Abrahams wrote:
"Jeff Garland" <jeff <at> crystalclearsoftware.com> writes:
I have my doubts that they are comparible in size w.r.t number of users. Are these internal projects or external projects?
I can't answer this one... Doug?
These are internal projects, mainly, so they have fewer users than Boost. There are some big users of subversion listed on their propaganda page:
http://subversion.tigris.org/propaganda.html
I think we can be reasonably assured that the Subversion software can handle the Boost repository.
I don't know exactly the size of the Boost repository, but you might find this post regarding the size of the repository of Apache Software Foundation interesting: <http://svn.haxx.se/dev/archive-2005-02/0263.shtml> Best Regards, Jani P.S. Please CC: me if seen as relevant, I am not on the list, thanks.
On Mon, 31 Jan 2005 11:17:21 -0500, David Abrahams wrote
I'm all for being methodical, but honestly if boost development ground to a halt for a couple of days I think we'd survive.
Sure, but what if the new environment is actually worse in some significant way? (yes, more FUD from a fuddy duddy). But the fact is, there won't be any going back to CVS once we are converted.
my view. Since we moved the mailing lists there have been issues that never got resolved -- specifically, the archive seems to lose messages or get stuck
That archiving software ** sucks **. Subversion is, in my experience, much better engineered.
Fair enough. Why did we choose it? How come we didn't test it before changing? Seems like we have the same level of process in this new selection...
Maybe we need to have a coordinated test where we all agree to pull down the whole repository at a certain time -- just to make sure the machines/network/software is really up to the task?
That's a bad test IMO. If we all hit CVS at the same time, how good do you think the response time will be?
I don't know what the response would be with CVS and it doesn't matter. My point was that CVS/Sourceforge has been mostly handling whatever the concurrent load is today. Yes, there's a stuck lock, slow updates for some, but most of the time it works (what exactly was the CVS issue list driving this, because I can't really recall any discussion on the list about CVS disatisfaction?). What little I know about sourceforge is they replicate CVS across servers to support anonymous access, have big network connections, etc. If we knew what the average and peak load on the repository was we could easily test that out that subversion/OSL would meet our needs. But since we don't know I was just suggesting a test that would give us information. If 10 people can't operate on the respository at the same time then I'd be worried about converting.
Maybe there are other tests we should do before jumping ship?
Name 'em and we can consider them. Otherwise it's just FUD.
Well I guess it's all just total FUD since you already decided the one test I suggested to see if subversion can handle load is a bad idea. No sense in testing anything, I guess nothing can go wrong...
One last question, how much of our version history will we lose?
None.
Will be still be able to pull the 1.32 branch out of subversion
Yes.
Great -- there's 2 tests we can do once the repository is converted.
OSL has already done several conversions; it's not that complicated.
Well then it shouldn't be a big deal to put up a converted test repository for us to play with. Since this has apparently already been decided and no actual testing is required to make sure the new environment will be better -- resolving an unspecified set of issues with the current environment -- I suggest we get on with the work of conversion immediately: -- changing all the boost web pages that talk about CVS -- telling all the users to download and learn subversion clients -- creating SSL accounts (or whatever) at OSL for all boost developers -- setup anonymous access to the repository -- converting the repository -- getting regression testing switched over Since this will cost 'almost nothing' in time and energy from the boost community lets draw up a time table and move on. Jeff ps: And in case you didn't catch it in the tone, the last 2 paragraphs are drenched in sarcasm...
Since this will cost 'almost nothing' in time and energy from the boost community lets draw up a time table and move on.
Jeff
I must admit I do not have any issues wit cvs that would cause me to think about move. But it you believe that it's better .... One thing though. If we decide to move lets reserve month after next release and do it without a hurry and interuptions (quite frankly I don't believe at take less, but if we will manage to do it quicker - the better) Gennadiy
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
On Mon, 31 Jan 2005 11:17:21 -0500, David Abrahams wrote
I'm all for being methodical, but honestly if boost development ground to a halt for a couple of days I think we'd survive.
Sure, but what if the new environment is actually worse in some significant way? (yes, more FUD from a fuddy duddy). But the fact is, there won't be any going back to CVS once we are converted.
True.
That archiving software ** sucks **. Subversion is, in my experience, much better engineered.
Fair enough. Why did we choose it?
We didn't. It's the default with Mailman and nobody has been able to find something better that the OSL guys were willing to set up.
How come we didn't test it before changing? Seems like we have the same level of process in this new selection...
No, the process is being discussed here first in part so we can head off problems.
Maybe we need to have a coordinated test where we all agree to pull down the whole repository at a certain time -- just to make sure the machines/network/software is really up to the task?
That's a bad test IMO. If we all hit CVS at the same time, how good do you think the response time will be?
I don't know what the response would be with CVS and it doesn't matter.
Sure it does, if you want to prove that SVN will be worse.
My point was that CVS/Sourceforge has been mostly handling whatever the concurrent load is today. Yes, there's a stuck lock, slow updates
and commits, and logs, ...
for some, but most of the time it works (what exactly was the CVS issue list driving this, because I can't really recall any discussion on the list about CVS disatisfaction?).
What little I know about sourceforge is they replicate CVS across servers to support anonymous access, have big network connections, etc.
The slowness we're seeing in CVS would be there regardless of how much server support we had. CVS just wasn't designed to scale to projects the size of Boost. Much of the slowness when you update occurs entirely on your local machine.
If we knew what the average and peak load on the repository was we could easily test that out that subversion/OSL would meet our needs. But since we don't know I was just suggesting a test that would give us information. If 10 people can't operate on the respository at the same time then I'd be worried about converting.
When you say "we all agree to pull down the whole repository at a certain time" I didn't think you were talking about only 10 people, doing the typical things that they might do.
Maybe there are other tests we should do before jumping ship?
Name 'em and we can consider them. Otherwise it's just FUD.
Well I guess it's all just total FUD since you already decided the one test I suggested to see if subversion can handle load is a bad idea. No sense in testing anything, I guess nothing can go wrong...
I don't see how that follows. There are useful and un-useful experiments. I can't make a judgement that your proposal is in the latter category without causing all experiments to be useless?
OSL has already done several conversions; it's not that complicated.
Well then it shouldn't be a big deal to put up a converted test repository for us to play with.
True.
Since this has apparently already been decided
It has not; I only said we're talking about it.
and no actual testing is required to make sure the new environment will be better
That's not getting any funnier the more you say it.
-- resolving an unspecified set of issues with the current environment -- I suggest we get on with the work of conversion immediately:
We're not ready yet, and there's plenty to discuss.
-- changing all the boost web pages that talk about CVS
Premature, IMO.
-- telling all the users to download and learn subversion clients
Might be a good idea anyway.
-- creating SSL accounts (or whatever) at OSL for all boost developers
Premature, IMO.
-- setup anonymous access to the repository
Premature, IMO
-- converting the repository
Might be a good idea anyway.
-- getting regression testing switched over
Since this will cost 'almost nothing' in time and energy from the boost community lets draw up a time table and move on.
Still not funny.
Jeff
ps: And in case you didn't catch it in the tone, the last 2 paragraphs are drenched in sarcasm...
It's pungent. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Wed, 02 Feb 2005 17:20:41 -0500, David Abrahams wrote
How come we didn't test it before changing? Seems like we have the same level of process in this new selection...
No, the process is being discussed here first in part so we can head off problems.
Great. From the tone of your first response it didn't seem like it, since all of my suggestions were simply dismissed out of hand (a bad test or FUD) -- or at least that's how it seemed to me. But I'm over it now... My whole point in bringing up the mailing list move issues, was as an analogy to the current CVS situation. While SVN+OSL might appear to be the superior solution at first blush, it might have significant unknown downsides and it might not even solve the problem(s). We should do whatever we can practically do to figure out if there are downsides because, as we both agree, there isn't any going back once we jump.
Maybe we need to have a coordinated test where we all agree to pull down the whole repository at a certain time -- just to make sure the machines/network/software is really up to the task?
That's a bad test IMO. If we all hit CVS at the same time, how good do you think the response time will be?
I don't know what the response would be with CVS and it doesn't matter.
Sure it does, if you want to prove that SVN will be worse.
I'm not trying to prove that SVN will be worse. First of all, the proposal at hand changes 2 variables: the hosting provider and the configuration management system. The stated goal is to improve the performance and scalability of the boost repository. So SVN might be really scalable, but the machine/network that hosts it might not be up the the task -- or vice versa. So my proposed test was just brainstorming -- I was trying to think of ways that we could validate that OSL+SVN combo will be performant. Frankly, my guess is that SVN will be fine, but never having hosted an SVN server I have no idea what kind of machine / network connection it takes to do it well. I have no idea what kind of machine OSL will host on, what sort of network they have, and what other apps will be running on the server. We basically don't have any idea of the current average and peak load on the boost CVS repository. Basically it's a shot in the dark from my view -- I have no idea if making this move will be better or worse. Of course just setting up an experimental boost repository in SVN at OSL won't put any load on the SVN server. Since it will just be for experimentation there won't be users doing updates, developers will just be tinkering, etc. It won't validate that the goal of the effort will be met -- only serve as a way to get developers familiar with SVN. So that's where the idea of intentionally loading the server comes in. It ensures that we at least give it some sort of tryout...
My point was that CVS/Sourceforge has been mostly handling whatever the concurrent load is today. Yes, there's a stuck lock, slow updates
and commits, and logs, ...
As I said, I see more than adequate CVS performance and a couple others also seem reasonably satisfied as well. I don't see constant complaints on the list about CVS. So from my view there's no rush for this. But I recognize there are others interacting with CVS might have a different view.
The slowness we're seeing in CVS would be there regardless of how much server support we had. ...slight rearrangement of points... Much of the slowness when you update occurs entirely on your local machine.
I have a smoking machine on my desk -- I assure you it is faster than the CVS server ;-) Seriously though, this assertion is irrelevant and unproveable. The performance is impacted by lots of factors: server load, network speeds, etc.
CVS just wasn't designed to scale to projects the size of Boost.
In terms of files, simultaneous users, what's the 'unit of size'? If you mean number of files, well, I'll just disagree b/c I've worked on bigger projects effectively with CVS (closed fast LAN, dedicated fast server, fast clients). But probably more relevant, there are current open source projects much larger than Boost that use CVS (try KDE for example). Maybe they just don't care about performance -- I don't know. But anyway, we need to stop focusing on what CVS is supposedly designed to do or not do and get back to why we want to convert, what the benefits will be, and how we make sure we get the benefits without stepping on a landmine.
If we knew what the average and peak load on the repository was we could easily test that out that subversion/OSL would meet our needs. But since we don't know I was just suggesting a test that would give us information. If 10 people can't operate on the respository at the same time then I'd be worried about converting.
When you say "we all agree to pull down the whole repository at a certain time" I didn't think you were talking about only 10 people, doing the typical things that they might do.
Sorry, I was a little loose with my test plan definition -- 'all' wasn't a wise word. As I said above, just putting the repository out there doesn't test the performance -- so that's what I was trying to define. A test to make sure the new perfomance will be good. 10 users doing checkout against the repository would probably be a good test. 100 users would be a stress test.
...snip...
-- changing all the boost web pages that talk about CVS
Premature, IMO.
Agree.
-- telling all the users to download and learn subversion clients
Might be a good idea anyway.
Agree.
-- creating SSL accounts (or whatever) at OSL for all boost developers
Premature, IMO.
How are we going to test the repository at OSL without this? Won't SSL be required for development access? Running checkouts thru SSL is likely to be slower and put more load on the server than without encrypting.
-- setup anonymous access to the repository
Premature, IMO
Needed for performance testing.
-- converting the repository
Might be a good idea anyway.
A foundational test in my mind.
-- getting regression testing switched over
I brought this list up to enumerate some of the costs of converting. There is non-trivial cost and I would hope there would be enough benefit to justify the costs. Personally I'm not sure I see it, but I'm willing to be pursuaded. Jeff
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
On Wed, 02 Feb 2005 17:20:41 -0500, David Abrahams wrote
How come we didn't test it before changing? Seems like we have the same level of process in this new selection...
No, the process is being discussed here first in part so we can head off problems.
Great. From the tone of your first response it didn't seem like it,
Check the subject line. The question mark there was intentional.
since all of my suggestions were simply dismissed out of hand (a bad test or FUD) -- or at least that's how it seemed to me.
IIRC you made only one suggestion, which after some consideration I thought was not a good test. The rest were just fears with no proposal for action, again IIRC.
But I'm over it now...
Good :^)
My whole point in bringing up the mailing list move issues, was as an analogy to the current CVS situation. While SVN+OSL might appear to be the superior solution at first blush, it might have significant unknown downsides and it might not even solve the problem(s). We should do whatever we can practically do to figure out if there are downsides because, as we both agree, there isn't any going back once we jump.
Well, we can certainly do some serious testing without jumping. And, in fact, there is going back. It would be very painful, but we could generate a script from the SVN repository and ask the SF guys to run it. But I'd rather avoid that.
Maybe we need to have a coordinated test where we all agree to pull down the whole repository at a certain time -- just to make sure the machines/network/software is really up to the task?
That's a bad test IMO. If we all hit CVS at the same time, how good do you think the response time will be?
I don't know what the response would be with CVS and it doesn't matter.
Sure it does, if you want to prove that SVN will be worse.
I'm not trying to prove that SVN will be worse. First of all, the proposal at hand changes 2 variables: the hosting provider and the configuration management system. The stated goal is to improve the performance and scalability of the boost repository. So SVN might be really scalable, but the machine/network that hosts it might not be up the the task
From what I've been told, OSL has a fast connection, and loads of money for equipment and good support, which is why I feel confident about that part of it. Andy, please correct me if I'm wrong.
-- or vice versa.
?? The task might not be up to the machine/network?
So my proposed test was just brainstorming -- I was trying to think of ways that we could validate that OSL+SVN combo will be performant.
I think deductive reasoning is probably the best approach on this one, because I don't think we're going to be able to create a sufficiently wide range of realistic usage patterns. Not least because we don't know how many people are using the CVS, and how.
Frankly, my guess is that SVN will be fine, but never having hosted an SVN server I have no idea what kind of machine / network connection it takes to do it well.
Again, deductive reasoning is probably a good tool here: find out what gets sent across the network; do some research into the relative demands of CVS and SVN on resources.
I have no idea what kind of machine OSL will host on, what sort of network they have, and what other apps will be running on the server.
I think those details are easy to discover, but even more so I think OSL will do what's neccessary to be sure the resources are sufficient.
We basically don't have any idea of the current average and peak load on the boost CVS repository. Basically it's a shot in the dark from my view -- I have no idea if making this move will be better or worse.
Of course just setting up an experimental boost repository in SVN at OSL won't put any load on the SVN server. Since it will just be for experimentation there won't be users doing updates, developers will just be tinkering, etc. It won't validate that the goal of the effort will be met -- only serve as a way to get developers familiar with SVN. So that's where the idea of intentionally loading the server comes in. It ensures that we at least give it some sort of tryout...
I like it in principle, but without the information you mentioned earlier about the CVS repository loads, how will we draw any conclusions from the results?
My point was that CVS/Sourceforge has been mostly handling whatever the concurrent load is today. Yes, there's a stuck lock, slow updates
and commits, and logs, ...
As I said, I see more than adequate CVS performance and a couple others also seem reasonably satisfied as well. I don't see constant complaints on the list about CVS. So from my view there's no rush for this. But I recognize there are others interacting with CVS might have a different view.
The slowness we're seeing in CVS would be there regardless of how much server support we had. ...slight rearrangement of points... Much of the slowness when you update occurs entirely on your local machine.
I have a smoking machine on my desk -- I assure you it is faster than the CVS server ;-) Seriously though, this assertion is irrelevant and unproveable.
Not completely. As the first step in updating CVS churns through all the files in your working copy.
The performance is impacted by lots of factors: server load, network speeds, etc.
CVS just wasn't designed to scale to projects the size of Boost.
In terms of files, simultaneous users,
Yes.
what's the 'unit of size'? If you mean number of files, well, I'll just disagree b/c I've worked on bigger projects effectively with CVS (closed fast LAN, dedicated fast server, fast clients).
That doesn't mean it was designed for the purpose.
But probably more relevant, there are current open source projects much larger than Boost that use CVS (try KDE for example). Maybe they just don't care about performance -- I don't know. But anyway, we need to stop focusing on what CVS is supposedly designed to do or not do and get back to why we want to convert, what the benefits will be, and how we make sure we get the benefits without stepping on a landmine.
Well, maybe we don't want to convert. If I'm the only one with complaints, it probably isn't a good idea.
If we knew what the average and peak load on the repository was we could easily test that out that subversion/OSL would meet our needs. But since we don't know I was just suggesting a test that would give us information. If 10 people can't operate on the respository at the same time then I'd be worried about converting.
When you say "we all agree to pull down the whole repository at a certain time" I didn't think you were talking about only 10 people, doing the typical things that they might do.
Sorry, I was a little loose with my test plan definition -- 'all' wasn't a wise word. As I said above, just putting the repository out there doesn't test the performance -- so that's what I was trying to define. A test to make sure the new perfomance will be good. 10 users doing checkout against the repository would probably be a good test. 100 users would be a stress test.
Okay, that sounds reasonable. Although I doubt cvs checkout is ever done by more than a few people at once. More likely update.
-- changing all the boost web pages that talk about CVS
Premature, IMO.
Agree.
-- telling all the users to download and learn subversion clients
Might be a good idea anyway.
Agree.
-- creating SSL accounts (or whatever) at OSL for all boost developers
Premature, IMO.
How are we going to test the repository at OSL without this? Won't SSL be required for development access?
Probably. But we don't need access for "all" boost developers, unless by "all" you mean ten of us again.
Running checkouts thru SSL is likely to be slower and put more load on the server than without encrypting.
I'm not sure whether encryption is actually used for anything other than authentication, but your point is taken nonetheless.
-- setup anonymous access to the repository
Premature, IMO
Needed for performance testing.
You don't think we can do the tests with 10 developers' https:// access? Not that I object to setting up anonymous access, or anything.
-- converting the repository
Might be a good idea anyway.
A foundational test in my mind.
Yep.
-- getting regression testing switched over
I brought this list up to enumerate some of the costs of converting. There is non-trivial cost and I would hope there would be enough benefit to justify the costs. Personally I'm not sure I see it, but I'm willing to be pursuaded.
I don't have much to say other than to say that some of us spend a lot of time waiting for CVS, there are constant stale locks, our occasional file moves are painful, and the anonymous pserver image lags the real one by an hour or more. Oh, and SF's connection for getting the CVS tarball keeps dropping, so it's hard for anyone to do automated backups. But if you aren't having any trouble, there may not be much anyone can do to persuade. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Thu, 03 Feb 2005 10:13:20 -0500, David Abrahams wrote
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
Great. From the tone of your first response it didn't seem like it,
Check the subject line. The question mark there was intentional.
That was subtle, didn't enter into my thinking later...
since all of my suggestions were simply dismissed out of hand (a bad test or FUD) -- or at least that's how it seemed to me.
IIRC you made only one suggestion, which after some consideration I thought was not a good test.
I think the problem was you didn't say why -- we've clarified that since...
The rest were just fears with no proposal for action, again IIRC.
Well, my sentence had a question mark too -- I was basically asking if others had good ideas for tests. I'd say some have since emerged...
Well, we can certainly do some serious testing without jumping. And, in fact, there is going back. It would be very painful, but we could generate a script from the SVN repository and ask the SF guys to run it. But I'd rather avoid that.
The pain of going back would be pretty difficult to imagine...
From what I've been told, OSL has a fast connection, and loads of money ^^^^^^^^^^^^ That's suprising, but if it's true, that's great.
-- or vice versa.
?? The task might not be up to the machine/network?
I'll try again. Since we are changing 2 variables: SVN and the hosting, one or the other might not be up to the challenge.
I think deductive reasoning is probably the best approach on this one, because I don't think we're going to be able to create a sufficiently wide range of realistic usage patterns. Not least because we don't know how many people are using the CVS, and how.
Frankly, my guess is that SVN will be fine, but never having hosted an SVN server I have no idea what kind of machine / network connection it takes to do it well.
Again, deductive reasoning is probably a good tool here: find out what gets sent across the network; do some research into the relative demands of CVS and SVN on resources.
I don't really want to argue this any more. Let's just agree to disagree. I don't believe logic will work with all the unknown variables. I think some sort set of tests are required to validate that the new environment won't just fall flat on it's face.
Of course just setting up an experimental boost repository in SVN at OSL won't put any load on the SVN server. ...
I like it in principle, but without the information you mentioned earlier about the CVS repository loads, how will we draw any conclusions from the results?
The only conclusion we can draw is that whatever test we do didn't break things. It's far from perfect, but I still prefer this to reading about what the software supposedly does and doesn't do and guessing at whether it will work.
A test to make sure the new perfomance will be good. 10 users doing checkout against the repository would probably be a good test. 100 users would be a stress test.
Okay, that sounds reasonable. Although I doubt cvs checkout is ever done by more than a few people at once. More likely update.
Sure update is fine. However, since SVN wants atomic repository commits maybe we should have someone do a big checkin while others are updating.
-- creating SSL accounts (or whatever) at OSL for all boost developers
Premature, IMO.
How are we going to test the repository at OSL without this? Won't SSL be required for development access?
Probably. But we don't need access for "all" boost developers, unless by "all" you mean ten of us again.
Well we can start with some subset, but all (this is really all ;-) of us will need to get used to the new environment over some period of time. Even if there is some other place to do that, I'd prefer to use something as close as possible to the final environment -- hate to learn details that don't turn out to be relevant to the final solution.
Running checkouts thru SSL is likely to be slower and put more load on the server than without encrypting.
I'm not sure whether encryption is actually used for anything other than authentication, but your point is taken nonetheless.
Should probably only be required for autentication to allow write access since we don't have any info we are trying to keep hidden. But someone will have to work out the details of the security model.
-- setup anonymous access to the repository
Premature, IMO
Needed for performance testing.
You don't think we can do the tests with 10 developers' https:// access? Not that I object to setting up anonymous access, or anything.
It might be enough to do 10, but do you think that's representative of the peak load on the repository? Anyway, whomever designs the security model will have to figure this out and set it up anyway.
I don't have much to say other than to say that some of us spend a ^^^^^^^^^^ Haven't heard from too many others yet in this thread...speak up folks, this isn't the Dave and Jeff show...
lot of time waiting for CVS, there are constant stale locks, our
Constant being once a day, week, month? Of course, it takes a long time to get SF folks to fix this so it's a big pain when it happens...
occasional file moves are painful,
No doubt SVN would be better at this. Directory versioning would be very nifty to have as well.
and the anonymous pserver image lags the real one by an hour or more.
Agree, that's a pain for me too.
Oh, and SF's connection for getting the CVS tarball keeps dropping, so it's hard for anyone to do automated backups.
Ok, since I don't pull those I wouldn't see that. Of course this is really a SF problem not a CVS problem. But obviously this could be improved by moving to OSL.
But if you aren't having any trouble, there may not be much anyone can do to persuade.
Well, I'm persuaded we should continue investigating the option if we have volunteers willing to put in time -- which it sounds like we do. But I think the process will take months. We will need to have a someone at OSL to work all the setup details (passwords, berkley db or fsfs, anonymous access, CVS conversion, etc, etc). It's going to be alot of work.... The only other nagging thing for me is while we spend our energy going down this path, the review queue is stuck b/c we haven't found a review manager to run the Wave review (I think I saw 2 posts from Tom with no answer). So we need others to step forward so we don't lose our momentum on library building front... Jeff
Jeff Garland wrote:
Subversion isn't a realistic choice at the moment unless we are going to move away from sourceforge for repository hosting. Quoting from the docs at:
http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1#alternateversioning
CVS is not the only version control system available in the world. One (very promising) version control system currently under development is Subversion. Subversion, an Open Source version control system (like CVS), has been designed to solve a number of the design flaws found in CVS.
At this time, Subversion is still under heavy development and has not yet reached the level of stability and maturity needed to provide production-grade Subversion services from SourceForge.net. The SourceForge.net team is continuing to evaluate the progress of the Subversion development process and will consider providing Subversion services once a suitable level of maturity has been reached.
Sure, one would have to host somewhere other than sourceforge to use subversion. I was under the impression that this was an option but couldn't find the posts in the archive. I'm guessing the sourceforge quote above is a year old, and though it may have been accurate when it was written, it isn't anymore. There have been fifteen releases of SVN in the last year (since 1.0), and only one of which has had new features, the rest have been bug/security fixes. The subversion developers are doing an excellent job in this regard. troy d. straszheim
Jeff Garland wrote:
Subversion isn't a realistic choice at the moment unless we are going to move away from sourceforge for repository hosting. Quoting from the docs at:
http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1#alternateversioning
CVS is not the only version control system available in the world. One (very promising) version control system currently under development is Subversion. Subversion, an Open Source version control system (like CVS), has been designed to solve a number of the design flaws found in CVS.
At this time, Subversion is still under heavy development and has not yet reached the level of stability and maturity needed to provide production-grade Subversion services from SourceForge.net. The SourceForge.net team is continuing to evaluate the progress of the Subversion development process and will consider providing Subversion services once a suitable level of maturity has been reached.
Sure, one would have to host somewhere other than sourceforge to use subversion. I was under the impression that this was an option but couldn't find the posts in the archive. I'm guessing the sourceforge quote above is a year old, and though it may have been accurate when it was written, it isn't anymore. There have been fifteen releases of SVN in the last year (since 1.0), and only one of which has had new features, the rest have been bug/security fixes. The subversion developers are doing an excellent job in this regard. troy d. straszheim
Jeff Garland wrote:
Subversion isn't a realistic choice at the moment unless we are going to move away from sourceforge for repository hosting. Quoting from the docs at:
http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1#alternateversioning
CVS is not the only version control system available in the world. One (very promising) version control system currently under development is Subversion. Subversion, an Open Source version control system (like CVS), has been designed to solve a number of the design flaws found in CVS.
At this time, Subversion is still under heavy development and has not yet reached the level of stability and maturity needed to provide production-grade Subversion services from SourceForge.net. The SourceForge.net team is continuing to evaluate the progress of the Subversion development process and will consider providing Subversion services once a suitable level of maturity has been reached.
Sure, one would have to host somewhere other than sourceforge to use subversion. I was under the impression that this was an option but couldn't find the posts in the archive. I'm guessing the sourceforge quote above is a year old, and though it may have been accurate when it was written, it isn't anymore. There have been fifteen releases of SVN in the last year (since 1.0), and only one of which has had new features, the rest have been bug/security fixes. The subversion developers are doing an excellent job in this regard. troy d. straszheim
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%2dco... Regards, -- Dave Abrahams Boost Consulting www.boost-consulting.com
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%2dco...
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. However, I am not a big fan of centralized version control, and vastly prefer a distributed approach. Distributed systems let people use version control when they are not connected to a central server, so when the server goes down you can still get work down. So the problem that spawned this thread about a CVS lock is much less of an issue. In fact, if the central server goes down unexpectedly, it is relatively easy to set up a new server somewhere else. Also, it is much easier for people to make private branches and contribute changes. No one needs accounts just to get work done. This blog entry summarizes it rather well http://web.verbum.org/blog/freesoftware/distributed-future In any case, there are a few different free decentralized version control systems. Darcs www.darcs.net Very easy to use. Fairly mature with good windows support, but it has some performance problems. It will probably have problems with a project the size of Boost. tla wiki.gnuarch.org Mature, but overly complex and has some annoying limitations. The windows client is definitely a second-class citizen. Should be fast enough for Boost. Monotone www.venge.net/monotone Beta. Windows support is relatively good. Well engineered, but unsure about speed with Boost. svk svk.elixus.org Beta. Adds distributed capabilities to subversion. It is the Rodney Dangerfield of version control systems: it doesn't get any respect. However, I don't see any obvious problems with it. ArX www.nongnu.org/arx/ Beta. This is my personal project. Windows requires cygwin. I personally use it to version control Boost, and it works well for me. In fact, it is probably the fastest of all of these for most common local operations. There are other differences, but I will spare you the details. Realistically, no change will work unless a major contributor to Boost gets religion and invests some time in learning one of them. All of these systems, including Subversion, have their annoying differences from CVS. It sounds like Subversion has such a convert with David Abrahams. Cheers, Walter Landry wlandry@ucsd.edu
Walter Landry <wlandry@ucsd.edu> writes:
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%2dco...
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.
I agree, it's very interesting. I recommend that everyone interested in the transition read at least the first message in that thread. I use cvs annotate less often than Mono developers, around once a week. If svn blame is 10x slower it will be a little bit annoying for me, but not intolerable. I'm less sure how the cultural issues will play out for us. I hope we're more adaptable than those Mono guys, but there's only one way to find out for sure.
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.
Hmm, I hadn't read about that before. Looks good! http://svnbook.red-bean.com/en/1.1/ch05.html#svn-ch-5-sect-1.3.2
However, I am not a big fan of centralized version control, and vastly prefer a distributed approach. Distributed systems let people use version control when they are not connected to a central server, so when the server goes down you can still get work down.
?? I get work done when disconnected from CVS.
So the problem that spawned this thread about a CVS lock is much less of an issue. In fact, if the central server goes down unexpectedly, it is relatively easy to set up a new server somewhere else.
That's a nice feature.
Also, it is much easier for people to make private branches and contribute changes. No one needs accounts just to get work done. This blog entry summarizes it rather well
http://web.verbum.org/blog/freesoftware/distributed-future
In any case, there are a few different free decentralized version control systems.
Darcs www.darcs.net Very easy to use. Fairly mature with good windows support, but it has some performance problems. It will probably have problems with a project the size of Boost.
Sounds like a poor choice, then.
tla wiki.gnuarch.org Mature, but overly complex and has some annoying limitations. The windows client is definitely a second-class citizen. Should be fast enough for Boost.
Sounds like a poor choice due to annoying limitations and poor Windows support.
Monotone www.venge.net/monotone Beta. Windows support is relatively good. Well engineered, but unsure about speed with Boost.
Only on release 0.16. I don't think it's ready for us.
svk svk.elixus.org Beta. Adds distributed capabilities to subversion. It is the Rodney Dangerfield of version control systems: it doesn't get any respect. However, I don't see any obvious problems with it.
My biggest concern is that it might not be widely adopted. Subversion seems to be the de-facto successor to CVS, and therefore I think it has a strong future. Secondary concern: it's written in Perl (only half-joking). Tertiary concern: only on release 0.29
ArX www.nongnu.org/arx/ Beta. This is my personal project. Windows requires cygwin.
I think that's a problem for many windows users. I love having cygwin, but apparently it is anathema to some.
I personally use it to version control Boost, and it works well for me. In fact, it is probably the fastest of all of these for most common local operations.
Biggest concern is the same, but even more so: there seems to be even less momentum for adoption than with svk. That said, it seems as though you can use svk on top of a centralized svn repository (arx too?) so maybe people can get this sort of functionality even if we adopt svn?
There are other differences, but I will spare you the details.
Realistically, no change will work unless a major contributor to Boost gets religion and invests some time in learning one of them. All of these systems, including Subversion, have their annoying differences from CVS. It sounds like Subversion has such a convert with David Abrahams.
I'm not a "convert," and my experience with svn is limited. I'm still in the early phases of experience with it. SVN seems like the logical choice to me, but I'm open to considering others. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
svk svk.elixus.org Beta. Adds distributed capabilities to subversion. It is the Rodney Dangerfield of version control systems: it doesn't get any respect. However, I don't see any obvious problems with it.
My biggest concern is that it might not be widely adopted. Subversion seems to be the de-facto successor to CVS, and therefore I think it has a strong future. Secondary concern: it's written in Perl (only half-joking). Tertiary concern: only on release 0.29
...
That said, it seems as though you can use svk on top of a centralized svn repository (arx too?) so maybe people can get this sort of functionality even if we adopt svn?
Yeah, that's the point. It's a wrapper that you can do local commits to. Personally I have no problem just keeping a mobile repository as well and doing my commits to the mother archive via "cp" from local checkout to mother checkout when I'm connected, but whatever, I guess there svk offers some slickness if you want to mess with it.
I'm not a "convert," and my experience with svn is limited. I'm still in the early phases of experience with it. SVN seems like the logical choice to me, but I'm open to considering others.
I have already done a couple of cvs->svn conversions for large projects. There is a bit of flexibility in how to do it... the offer stands to do some test runs and make the svn archives open, to play with. This way you can give the OSL guys a properly tweaked conversion script when you're ready, not just have the archive dumped through cvs2svn. I wonder specifically if boost would be best set up with toplevel trunk/branches/tags, or if it would be best to do this somehow per-library, linked up with svn:externals. Depends on what the CVS archive's tags/branches/etc look like, this has a lot to do with it when it comes to preserving this history information in the converted archive. I just need a tarball of CVS. -t
"troy d. straszheim" <troy@resophonic.com> writes:
David Abrahams wrote:
svk svk.elixus.org Beta. Adds distributed capabilities to subversion. It is the Rodney Dangerfield of version control systems: it doesn't get any respect. However, I don't see any obvious problems with it. My biggest concern is that it might not be widely adopted. Subversion seems to be the de-facto successor to CVS, and therefore I think it has a strong future. Secondary concern: it's written in Perl (only half-joking). Tertiary concern: only on release 0.29
...
That said, it seems as though you can use svk on top of a centralized svn repository (arx too?) so maybe people can get this sort of functionality even if we adopt svn?
Yeah, that's the point. It's a wrapper that you can do local commits to. Personally I have no problem just keeping a mobile repository as well and doing my commits to the mother archive via "cp" from local checkout to mother checkout when I'm connected, but whatever, I guess there svk offers some slickness if you want to mess with it.
I'm not a "convert," and my experience with svn is limited. I'm still in the early phases of experience with it. SVN seems like the logical choice to me, but I'm open to considering others.
I have already done a couple of cvs->svn conversions for large projects. There is a bit of flexibility in how to do it... the offer stands to do some test runs and make the svn archives open, to play with. This way you can give the OSL guys a properly tweaked conversion script when you're ready, not just have the archive dumped through cvs2svn.
I never saw such an offer. If you're offering, for my part, I *think* I accept, and gratefully... but could you elaborate? I'm not sure I understand the specific details of what you're proposing.
wonder specifically if boost would be best set up with toplevel trunk/branches/tags, or if it would be best to do this somehow per-library
Probably a mix would be best. Release tags need to go at the top level, right?
, linked up with svn:externals.
Not familiar with that. Link?
Depends on what the CVS archive's tags/branches/etc look like, this has a lot to do with it when it comes to preserving this history information in the converted archive. I just need a tarball of CVS.
That's easy to get; meta-comm is posting it at http://www.meta-comm.com/engineering/index.html -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"troy d. straszheim" <troy@resophonic.com> writes:
Depends on what the CVS archive's tags/branches/etc look like, this has a lot to do with it when it comes to preserving this history information in the converted archive. I just need a tarball of CVS.
That's easy to get; meta-comm is posting it at http://www.meta-comm.com/engineering/index.html
I think Troy needs an archive of the CVS repository.. Not a snapshot of the trunk. Otherwise he would have all the history of the files. Don't remember where SF publishes those.. And if they still are publishing them... Here's the link.. http://cvs.sourceforge.net/cvstarballs/boost-cvsroot.tar.bz2 Not sure about the integrity of it. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Here's an interesting read. The developer of PuTTY (a popular Telnet/SSH client) switched from CVS to SVN and wrote about his experiences: http://www.chiark.greenend.org.uk/~sgtatham/svn.html -- Caleb Epstein caleb dot epstein at gmail dot com
On Wed, 2 Feb 2005 22:23:56 -0500, Caleb Epstein wrote
Here's an interesting read. The developer of PuTTY (a popular Telnet/SSH client) switched from CVS to SVN and wrote about his experiences:
Interesting reading -- I've started collecting some of the links on a Wiki page: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Subversion_Co... Jeff
Rene Rivera <grafik.list@redshift-software.com> writes:
David Abrahams wrote:
"troy d. straszheim" <troy@resophonic.com> writes:
Depends on what the CVS archive's tags/branches/etc look like, this has a lot to do with it when it comes to preserving this history information in the converted archive. I just need a tarball of CVS. That's easy to get; meta-comm is posting it at http://www.meta-comm.com/engineering/index.html
I think Troy needs an archive of the CVS repository..
I thought that's what they were posting, sorry.
Not a snapshot of the trunk. Otherwise he would have all the history of the files. Don't remember where SF publishes those.. And if they still are publishing them...
Yeah, they do.
Here's the link..
http://cvs.sourceforge.net/cvstarballs/boost-cvsroot.tar.bz2
Not sure about the integrity of it.
Last time I checked, I needed an error-correcting http link to get it. IOW, "wget" would fail about 4 out of 5 times. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Thu, 03 Feb 2005 09:23:54 -0500, David Abrahams <dave@boost-consulting.com> wrote:
Last time I checked, I needed an error-correcting http link to get it. IOW, "wget" would fail about 4 out of 5 times.
wget -c -t 0 ? -- Caleb Epstein caleb dot epstein at gmail dot com
This didn't seem to go through first time, resend... David Abrahams wrote:
I have already done a couple of cvs->svn conversions for large projects. There is a bit of flexibility in how to do it... the offer stands to do some test runs and make the svn archives open, to play with. This way you can give the OSL guys a properly tweaked conversion script when you're ready, not just have the archive dumped through cvs2svn.
I never saw such an offer. If you're offering, for my part, I *think* I accept, and gratefully... but could you elaborate? I'm not sure I understand the specific details of what you're proposing.
OK, I'll type louder next time... :) Main thing I'm offering is elbow grease and a test repository so that there are concrete answers to questions like this (I see the thread has continued as I write this mail): Jeff Garland wrote:
Sure, but what if the new environment is actually worse in some significant way? (yes, more FUD from a fuddy duddy). But the fact is, there won't be any going back to CVS once we are converted.
wonder specifically if boost would be best set up with toplevel
I just thought it would be good to actually beat on an svn repository. And I have one finished. But if it's OK I'd like to open it up to just library authors or some smaller set of people first, since it's not a bandwidth test. Don't know how to establish what this smaller set should be. Mail me privately? I can put some scripts into motion on the box itself to stress the archive without loading the pipe. My initial estimate was that the conversion would take a long time to get right. I got a tarball of the CVS repository from sourceforge (thanks Rene) and upon trying to put it through cvs2svn this came up: ERROR: The following symbols are tags in some files and branches in others. Use --force-tag, --force-branch and/or --exclude to resolve the symbols. 'RC_1_30_0' is a tag in 11 files, a branch in 6513 files and has commits in 2605 files. These conversions have to be done in one pass like a database load, so after that error you do Not Pass Go. In the last project I did it took hours and hours to get this all right, there were heaps of those, but it turns out that most of the problems I had there don't turn up in boost's case. trunk/branches/tags, or if it would be best to do this somehow per-library
Probably a mix would be best. Release tags need to go at the top level, right?
So the convention with SVN is to put the trunk in "trunk/", tags in "tags/", and branches in "branches/", but that is only convention, and they came up with that convention presumably because it is comprehensible to people are used to thinking in terms of CVS. cvs2svn sets things up like this by default. But SVN doesn't really know or care how this is organized, and it doesn't enforce no-committing-to-directories-located-under-tags or anything... So it would be possible to do releases/, release-candidates/, regressions/, and miserable-failures/ as well. Dunno. When you run cvs2svn w/o tweaking it, all branches and tags that were created in the directory tree appear at the top level. For instance, the "branches" directory for a freshly converted boost repository contains the following subdirectories:
Revision 19694: /branches
* .. * FUSION_MSVC/ * RC_1_27_0/ * RC_1_28_0/ * RC_1_29_0/ * RC_1_30_0/ * RC_1_31_0/ * RC_1_32_0/ * SPIRIT_1_6/ * SPIRIT_MINIBOOST/ * SPIRIT_RC_1_6_2/ * SPIRIT_RC_1_8_2/ * aix_so/ * alternative_regression/ * bbv1_cross_project/ * better_indirect/ * boost/ * boost++graph/ * boost-graph-library/ * boost_build_v2/ * boost_python_friend_fixes/ * boost_python_richcmp/ * boostify/ * build/ * build-developement/ * build-development/ * build-development-2/ * build-development-gcc-unix/ * build_development-gcc-unix/ * build_for_distribution/ * build_system/ * coding_guidelines/ * coercion_experiments/ * compiler_supported_error_messages/ * conversion/ * cursor/ * data_driven/ * error_handling/ * feature_branch-update_rule/ * fs_review/ * function_signature_patches_1_31/ * function_v2/ * graph_devel/ * graph_devel_1_33_0/ * indexing_v2/ * iter-adaptor-and-categories/ * iterator-adaptors/ * iterator_adaptor_update/ * jam-src/ * jam_src/ * lambda_development/ * lambda_development_during_review/ * langbinding/ * matrix_development/ * more1/ * moved_pointer/ * mpl-development/ * mpl_v2/ * mpl_v2_2/ * mplbook/ * named-args/ * newbpl/ * null_ptr_is_none/ * numerics/ * perforce_2_4_merge/ * perforce_jam_2_4/ * persistence-initial/ * pro7_void_returns/ * python/ * python-v2-dev/ * python_v2_API_restructure/ * ralf_grosse_kunstleve/ * regex-4/ * regex-4-1/ * regex-sub/ * regex5/ * rich_cons/ * rollback/ * sane-testing/ * shared_modules/ * simplify/ * split-config/ * test-development/ * thread-initial/ * thread_dev/ * thread_development/ * tmpw2001-paper/ * to_python_experiments/ * tuples_subnamespace/ * type_traits2/ * uBLAS_pure/ * unit_test_development/ * unlabeled-1.1.1/ * unlabeled-1.1.1.1.10/ * unlabeled-1.1.1.1.6/ * unlabeled-1.1.1.1.8/ * unlabeled-1.1.2/ * unlabeled-1.1.4/ * unlabeled-1.1.6/ * unlabeled-1.1.8/ * unlabeled-1.10.2/ * unlabeled-1.10.4/ * unlabeled-1.11.2/ * unlabeled-1.12.2/ * unlabeled-1.13.2/ * unlabeled-1.14.2/ * unlabeled-1.15.2/ * unlabeled-1.16.2/ * unlabeled-1.18.2/ * unlabeled-1.19.2/ * unlabeled-1.2.2/ * unlabeled-1.2.6/ * unlabeled-1.2.8/ * unlabeled-1.21.2/ * unlabeled-1.23.2/ * unlabeled-1.25.2/ * unlabeled-1.3.2/ * unlabeled-1.3.6/ * unlabeled-1.3.8/ * unlabeled-1.37.2/ * unlabeled-1.37.6/ * unlabeled-1.4.2/ * unlabeled-1.4.6/ * unlabeled-1.5.2/ * unlabeled-1.5.4/ * unlabeled-1.6.2/ * unlabeled-1.65.2/ * unlabeled-1.7.2/ * unlabeled-1.7.4/ * unlabeled-1.8.2/ * unlabeled-1.9.2/ * void_returns/ * wg21_random_proposal/
Which is the same as cvs status -v at the root directory would show you. Maybe a deeper hierarchy in the branch department would be better, or a trunk-only import, dunno. Lot of these don't look useful, a lot of them start in development/... You can't really tell where they were rooted, either, of course you don't get that information out of CVS either.
, linked up with svn:externals.
Not familiar with that. Link?
http://svnbook.red-bean.com/en/1.0/ch07s03.html I can't decide if this is worth thinking about more or not, I can already hear people objecting because it would change yet *more* variables than just CVS/sourceforge => SVN/OSL, and I thought I'd point the capability out for people to chew on a bit. You can add automatic checkouts of other projects to your project. So "miniboost" or whatever sub-distribution of boost could just be a project with a set of svn:external properties that looks something like, boost/type_traits http://svn.boost.org/trunk/boost/boost/type_traits libs/type_traits http://svn.boost.org/trunk/boost/libs/type_traits boost/preprocessor http://svn.boost.org/trunk/boost/boost/preprocessor libs/preprocessor http://svn.boost.org/trunk/boost/libs/preprocessor tools http://svn.boost.org/trunk/boost/tools or whatever. When you check out sub-boost, those five directories would be populated with source picked out of the middle of boost, and the individual "versions" of what gets picked out could vary from boost sublibrary to sublibrary, they wouldn't all have to be from the same main release of boost. Parallel to this there could be a mega-boost and whatever. And the svn:externals properties, in that list above, are versioned, so you basically have a mapping from a boost release number (the version of the sub-boost containing the externals) to a set of versions of component libraries. Which makes you want to think about per-library versioning, which for all I know might have already been tried and is Considered Harmful. This could conceivably make little releases easier to get out the door and little distributions easier to create... just as conceivably could create total mayhem... troy d. straszheim
Hrm. OK so it is at http://svn.resophonic.com/boost, mail me privately if you want write access.
At 12:11 AM 2/4/2005, troy d. straszheim wrote:
Hrm. OK so it is at http://svn.resophonic.com/boost, mail me privately if you want write access.
Thanks for doing this! I'm using it, and it worked first try. I'll post impressions in a couple of days, when I've tried more operations. --Beman
I was originally reluctant to just publish some login info completely in the open, lest the box get DOS'ed off the net, but the load on the box and the line have been light. So here goes, just use login "whoever" with password "whoever". -t Beman Dawes writes:
At 12:11 AM 2/4/2005, troy d. straszheim wrote:
Hrm. OK so it is at http://svn.resophonic.com/boost, mail me privately if you want write access.
Thanks for doing this! I'm using it, and it worked first try.
I'll post impressions in a couple of days, when I've tried more operations.
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
David Abrahams <dave@boost-consulting.com> writes:
, linked up with svn:externals.
Not familiar with that. Link?
The svn:externals property allows you to populate a sub-directory in your checkout with the contents of an external directory. The external directory can be from another part of the repository, or another repository entirely. It's a bit like an absolute symbolic link (it can not be relative). Read all about it at: http://svnbook.red-bean.com/en/1.1/ch07s03.html Robert Zeh http://home.earthlink.net/~rzeh
David Abrahams <dave@boost-consulting.com> wrote:
Walter Landry <wlandry@ucsd.edu> writes:
However, I am not a big fan of centralized version control, and vastly prefer a distributed approach. Distributed systems let people use version control when they are not connected to a central server, so when the server goes down you can still get work down.
?? I get work done when disconnected from CVS.
You can't commit. So you can't try some designs, settle on one, then realize a different design worked better and resurrect it. Basically, you lose many of the benefits of using version control. <snip>
There are other differences, but I will spare you the details.
Realistically, no change will work unless a major contributor to Boost gets religion and invests some time in learning one of them. All of these systems, including Subversion, have their annoying differences from CVS. It sounds like Subversion has such a convert with David Abrahams.
I'm not a "convert," and my experience with svn is limited. I'm still in the early phases of experience with it. SVN seems like the logical choice to me, but I'm open to considering others.
I think that svn is the logical choice if you want to stay with a centralized model. I just don't think that the centralized model is the best way. The distributed alternatives all have issues, but you have to weigh that against the problems with a centralized model. Obviously, the centralized model is not a deal-breaker, because Boost has been surviving with CVS. But it is important to understand what kind of problems you will have with any centralized model. For example, from a different email you wrote I don't have much to say other than to say that some of us spend a lot of time waiting for CVS, What kind of operations are you doing that require waiting? Some operations in distributed systems do not require talking to the central server at all. Even "update" will differ because the work patterns are different. In any case, getting a new host (OSL) may solve some of this. there are constant stale locks, This problem mostly goes away with distributed systems. our occasional file moves are painful, This goes away with any modern version control system. and the anonymous pserver image lags the real one by an hour or more. Oh, and SF's connection for getting the CVS tarball keeps dropping, so it's hard for anyone to do automated backups. These sound more like problems with sourceforge, not the version control system. So it really sounds like you should see how well the new host works with CVS before committing to svn. Cheers, Walter Landry wlandry@ucsd.edu
Walter Landry <wlandry@ucsd.edu> writes:
I think that svn is the logical choice if you want to stay with a centralized model. I just don't think that the centralized model is the best way.
If there's no central repository, how do you know what the "real" state of the codebase is? How does it get backed up? How does decentralization interact with automated testing?
The distributed alternatives all have issues, but you have to weigh that against the problems with a centralized model. Obviously, the centralized model is not a deal-breaker, because Boost has been surviving with CVS. But it is important to understand what kind of problems you will have with any centralized model.
For example, from a different email you wrote
I don't have much to say other than to say that some of us spend a lot of time waiting for CVS,
What kind of operations are you doing that require waiting?
Update, for one. And for that one substantial churn happens on the local machine before any bits move across the network. The others usually require some mildly annoying wait, too, but that's the biggie.
Some operations in distributed systems do not require talking to the central server at all. Even "update" will differ because the work patterns are different.
Details?
In any case, getting a new host (OSL) may solve some of this.
Maybe, but as I've been saying, the problems with update are substantially due to the way CVS works.
there are constant stale locks,
This problem mostly goes away with distributed systems.
And completely goes away with SVN.
our occasional file moves are painful,
This goes away with any modern version control system.
and the anonymous pserver image lags the real one by an hour or more. Oh, and SF's connection for getting the CVS tarball keeps dropping, so it's hard for anyone to do automated backups.
These sound more like problems with sourceforge, not the version control system.
Yes.
So it really sounds like you should see how well the new host works with CVS before committing to svn.
That's an interesting thought. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Walter Landry <wlandry@ucsd.edu> writes:
So it really sounds like you should see how well the new host works with CVS before committing to svn.
That's an interesting thought.
I wanted to comment, in backing the move from CVS to SVN, that I have found using SVN, particular with TortoiseSVN on Windows, immensely easier than using CVS, even with WinCVS. The fact that I can visually get the latest updates from any part of an SVN repository to any directory, that I can checkout from any part of an SVN directory to any directory, that I can commit at any level, that my copies, moves, and deletes are automatically picked up by SVN, makes SVN a no-brainer of a choice over CVS. I realize I do not know CVS nearly as well as I know SVN, but I do know that from the end user's perspective, SVN is sublimely easy to use and fairly easy to understand. I could never say that personally about CVS. That, even if all other things were equal between SVN and CVS, which I doubt given SVN's more integrated functionality, would be a good enough reason for me to switch from any CVS based system to an SVN based repository system, and I am very happy that the last company for whom I consulted, and the current company for whom I am employed, both use SVN. I have also found the SVN NGs, both the main one, gmane.comp.version-control.subversion.user, and the TortoiseSVN one, gmane.comp.version-control.subversion.tortoisesvn.devel, very helpful and responsive, and the documentation for Subversion and TortoiseSVN fairly decent. Finally another word about SVN. If using the Apache Server for the repository, as opposed to the SVN server, control of any path in a repository can be implemented. Without it, and using the SVN server, the only type of control occurs on the repository as a whole, which may be good enough if one wants to allow write access to a repository to a group of people, such as Boost developers, and read access to Boost users. Of course with SVN, one can set up as many repositories as one wants.
I wanted to comment, in backing the move from CVS to SVN, that I have found using SVN, particular with TortoiseSVN on Windows, immensely easier than using CVS, even with WinCVS.
Have you ever tried TortoiseCVS? I've been using ever since Boost started using cvs and love it; and my understanding is that it has basically the same feature set as TortoiceSVN. I looked at WinCVS once and immediately gave up! Just a satisfied user, John.
David Abrahams <dave@boost-consulting.com> wrote:
Walter Landry <wlandry@ucsd.edu> writes:
I think that svn is the logical choice if you want to stay with a centralized model. I just don't think that the centralized model is the best way.
If there's no central repository, how do you know what the "real" state of the codebase is? How does it get backed up? How does decentralization interact with automated testing?
This is explained more fully elsewhere [1] [2], but one way to do it is to have a centralized repository that people send merge requests to. So Boost might have a Grand Pooh-bah (GPB) who controls this repository. Developers branch off of this repository and, when they are done, ask the GPB to merge in their changes. If you trust your developers as much as you trust them now, you can make the GPB a robot that automatically merges in their changes. This is also called a patch queue, and there is one that exists for tla and ArX. However, it is pretty easy to retrofit it for other distributed version control systems.
The distributed alternatives all have issues, but you have to weigh that against the problems with a centralized model. Obviously, the centralized model is not a deal-breaker, because Boost has been surviving with CVS. But it is important to understand what kind of problems you will have with any centralized model.
For example, from a different email you wrote
I don't have much to say other than to say that some of us spend a lot of time waiting for CVS,
What kind of operations are you doing that require waiting?
Update, for one. And for that one substantial churn happens on the local machine before any bits move across the network.
Interesting. Subversion doesn't seem to be faster for that operation [3] [4]. However, there are claims that you don't have to do it as often [5]. YMMV. In general, I would say that there are lots of good reasons to switch away from CVS to something else, but performance is not one of them.
The others usually require some mildly annoying wait, too, but that's the biggie.
Some operations in distributed systems do not require talking to the central server at all. Even "update" will differ because the work patterns are different.
Details?
With a distributed system, you can do more work away from the central repository. So you may end up with fewer, larger patches. That impacts the speed of updates. At least, that is the theory. Also, with the better merge tools in the distributed systems, you don't have to run update all the time.
In any case, getting a new host (OSL) may solve some of this.
Maybe, but as I've been saying, the problems with update are substantially due to the way CVS works.
there are constant stale locks,
This problem mostly goes away with distributed systems.
And completely goes away with SVN.
It can never completely go away. If you have multiple people who can modify a repository, you have to have locks. Then things can happen (network goes away) that prevent you from freeing the lock. However, you can do a number of things to minimize how long you have to hold a lock, and how easy it is to remove a stale lock. For modern systems, it really boils down to a QOI issue. My impression of svn is that has improved a great deal since their early releases. Finally, I should mention that distributed systems are much, much better with experimental, throw-away branches because you don't have to clutter up a central repository with everyone's experiments. Cheers, Walter Landry wlandry@ucsd.edu [1] http://superbeast.ucsd.edu/~landry/ArX/ArX-2.2.0/tools/arch-pqm/arch-pqm.htm... [2] http://web.verbum.org/arch-pqm/ [3] http://blog.reverycodes.com/archives/000028.html [4] http://subversion.kicks-ass.org/perfnew/ [5] http://www.contactor.se/~dast/svnusers/archive-2004-09/0682.shtml
Walter Landry wrote:
David Abrahams <dave@boost-consulting.com> wrote:
In any case, getting a new host (OSL) may solve some of this.
Maybe, but as I've been saying, the problems with update are substantially due to the way CVS works.
there are constant stale locks,
This problem mostly goes away with distributed systems.
And completely goes away with SVN.
It can never completely go away. If you have multiple people who can modify a repository, you have to have locks. Then things can happen (network goes away) that prevent you from freeing the lock.
SVN does not have locks. If more than one person attempts to commit a file after someone else has made and committed changes at a later date than the initial date for the second person's working copy of the file, SVN prevents the change until a merge is done from the latest source on the repository. Of course there is an automatic merging mechanism which will help the second person to do their merge, but the general mechanism hold true. Now this may be described as a "lock" but actually nothing ever gets locked in the sense of retrieving data from the repository. The potential "lock" only occurs when one attempts to commit an updated copy. To me this is a big step in the conceptual model which CVS employs.
* David Abrahams <dave@boost-consulting.com> [2005-02-02 14:28]:
Walter Landry <wlandry@ucsd.edu> writes:
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%2dco...
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.
I agree, it's very interesting. I recommend that everyone interested in the transition read at least the first message in that thread.
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. -- Alan Gutierrez - alan@engrm.com
Alan Gutierrez <alan-boost@engrm.com> writes:
* David Abrahams <dave@boost-consulting.com> [2005-02-02 14:28]:
In any case, I hope you'll consider carefully, the project structure when you move away from the tag based system in CVS.
You bet. In a codebase like ours with independent but moderately-coupled libraries it can get tricky. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Alan Gutierrez <alan-boost@engrm.com> writes:
In any case, I hope you'll consider carefully, the project structure when you move away from the tag based system in CVS.
You bet. In a codebase like ours with independent but moderately-coupled libraries it can get tricky.
It would appear to a semi-lurking outsider, that spending a short time clarifying the structure of the libraries (even if just writing it down on the main web page) would be useful anyway. For instance, can Boost be considered as a 'Layered' structure, such as a 'Core layer' (Test, Bind, Shared Ptr, MPL ... TR1?) with some requirements that changing them should occur in a well structured way. The non-core libraries then sit on top of this and should have minimal dependancy on other things. This appears to be the intent in general, but its not always clear what unintentional dependancies exist. As an example if I want to get program options compiled for IRIX, I discovered I needed to fix Bind first, the release code can't begin to compile beyond the first error, and after that is fixed I find that there are some program options items that need fixing up, next to test it I needed a short Test fixup, now I can test the rest of boost (still running the tests after 24 hours ... oh well I won't be using the machine over the weekend :-) Now I can run things like bcp, which at a first pass needs filesystem, lexical_cast, regex, shared_ptr, mpl, preprocessor, iterator, etc etc. and this is fine as its not a library its a tool. I've also played with boost for a while now so I kind of know how its put together, but others coming to it? (I could also use doxygen and similar). I wonder if external people comming to boost might miss this structure being exposed to them in a clear way, perhaps improving the visibility of tools like bcp would help this (and providing downloadable binaries?) I certainly would recommend people to use it as its quite scary the number of files that potentially get used indirectly if you don't. Kevin (I suppose if I had a faster machine I'd spend less time commenting and more time doing :-) -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself |
At Monday 2005-01-31 14:26, you 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%2dco...
Regards, -- Dave Abrahams Boost Consulting www.boost-consulting.com
I check out boost from CVS (well update it) 4 times a day when I run the regression tests. I don't recall noticing any bad problems other than when someone put a very bad copy of some iostreams stuff in there.
_______________________________________________ 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"
David Abrahams 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%2dco...
Regards,
Can anyone comment on whether the branching has got better in svn? In particular (Quoting from http://www.gamesfromwithin.com/articles/0407/000026.html) <quote> Here's the real killer blow for me: Subversion doesn't keep track of what merges have been applied to a file. That's up to you to keep track of somehow. That means that for every file (or set of files), you have to know up to what revision they've been integrated, and only pull in the changes from that revision on.Here's the real killer blow for me: Subversion doesn't keep track of what merges have been applied to a file. That's up to you to keep track of somehow. That means that for every file (or set of files), you have to know up to what revision they've been integrated, and only pull in the changes from that revision on. </quote> This appears to be very limiting if you rely heavily on branching. cheers martin
Martin Slater wrote:
[...] Can anyone comment on whether the branching has got better in svn? In particular (Quoting from http://www.gamesfromwithin.com/articles/0407/000026.html)
I don't think it's changed.
<quote> Here's the real killer blow for me: Subversion doesn't keep track of what merges have been applied to a file. That's up to you to keep track of somehow. That means that for every file (or set of files), you have to know up to what revision they've been integrated, and only pull in the changes from that revision on. </quote>
This appears to be very limiting if you rely heavily on branching.
The SVN book, if I recall correctly, does mention this case. Their solution is to always comment merge transactions so that you can look at the history and identify them. Whether that is impractical for Boost or not, I can't say. Dave
The SVN book, if I recall correctly, does mention this case. Their solution is to always comment merge transactions so that you can look at the history and identify them. Whether that is impractical for Boost or not, I can't say.
Ok, thanks. Possibly something to bear in mind then, this was the major killer for us using svn at work as we intend to rely very heavily on branching for our day to day work on our upcoming project. cheers Martin
At Sunday 2005-02-06 03:16, you wrote:
The SVN book, if I recall correctly, does mention this case. Their solution is to always comment merge transactions so that you can look at the history and identify them. Whether that is impractical for Boost or not, I can't say.
Ok, thanks. Possibly something to bear in mind then, this was the major killer for us using svn at work as we intend to rely very heavily on branching for our day to day work on our upcoming project.
IIUC, cvsnt has a feature (called mergepoints) which automates tracking for you and eliminates the requirement for all those pesky tags to track merges.
cheers
Martin _______________________________________________ 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"
"David B. Held" <dheld@codelogicconsulting.com> writes:
Martin Slater wrote:
[...] Can anyone comment on whether the branching has got better in svn? In particular (Quoting from http://www.gamesfromwithin.com/articles/0407/000026.html)
I don't think it's changed.
<quote> Here's the real killer blow for me: Subversion doesn't keep track of what merges have been applied to a file. That's up to you to keep track of somehow. That means that for every file (or set of files), you have to know up to what revision they've been integrated, and only pull in the changes from that revision on. </quote> This appears to be very limiting if you rely heavily on branching.
The SVN book, if I recall correctly, does mention this case. Their solution is to always comment merge transactions so that you can look at the history and identify them. Whether that is impractical for Boost or not, I can't say.
There's a script called svnmerge that handles this, if you just agree to use that instead of svn's built-in merging. The SVN people appear to be unwilling to implement smart merging directly in SVN until they can do it perfectly. http://thread.gmane.org/gmane.comp.version-control.subversion.user/22053 -- Dave Abrahams Boost Consulting www.boost-consulting.com
Martin Slater wrote:
Can anyone comment on whether the branching has got better in svn? In particular (Quoting from http://www.gamesfromwithin.com/articles/0407/000026.html)
<quote> Here's the real killer blow for me: Subversion doesn't keep track of what merges have been applied to a file. That's up to you to keep track of somehow. That means that for every file (or set of files), you have to know up to what revision they've been integrated, and only pull in the changes from that revision on. [...Double quote deleted...] </quote>
This appears to be very limiting if you rely heavily on branching.
Is that any worse than the current situation with CVS? If not, it's not a problem IMHO. Regards, Daniel
On Feb 6, 2005, at 1:06 PM, Daniel Frey wrote:
Martin Slater wrote:
Can anyone comment on whether the branching has got better in svn? In particular (Quoting from http://www.gamesfromwithin.com/articles/0407/000026.html) <quote> Here's the real killer blow for me: Subversion doesn't keep track of what merges have been applied to a file. That's up to you to keep track of somehow. That means that for every file (or set of files), you have to know up to what revision they've been integrated, and only pull in the changes from that revision on. [...Double quote deleted...] </quote> This appears to be very limiting if you rely heavily on branching.
Is that any worse than the current situation with CVS? If not, it's not a problem IMHO.
It's exactly the way CVS works. Without clear and consistent naming of tags, tags used for branchpoints and branches, both CVS and Subversion will disappoint. Since SVN is the same as CVS in this regard I do not see this as a problem either. - Michael
Regards, Daniel
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
At Sunday 2005-02-06 04:45, you wrote:
On Feb 6, 2005, at 1:06 PM, Daniel Frey wrote:
Martin Slater wrote:
Can anyone comment on whether the branching has got better in svn? In particular (Quoting from http://www.gamesfromwithin.com/articles/0407/000026.html) <quote> Here's the real killer blow for me: Subversion doesn't keep track of what merges have been applied to a file. That's up to you to keep track of somehow. That means that for every file (or set of files), you have to know up to what revision they've been integrated, and only pull in the changes from that revision on. [...Double quote deleted...] </quote> This appears to be very limiting if you rely heavily on branching.
Is that any worse than the current situation with CVS? If not, it's not a problem IMHO.
It's exactly the way CVS works. Without clear and consistent naming of tags, tags used for branchpoints and branches, both CVS and Subversion will disappoint.
Since SVN is the same as CVS in this regard I do not see this as a problem either.
It's becoming apparent that the ONLY possibilities being considered are CVS (ancient history) and Subversion. Other than my mention of cvsnt and one other NOBODY is looking at it. not to put _too_ fine a point on it: CVSNT ELIMINATES THIS PROBLEM!!
- Michael
Regards, Daniel
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ 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. wrote:
At Sunday 2005-02-06 04:45, you wrote: [...] It's becoming apparent that the ONLY possibilities being considered are CVS (ancient history) and Subversion. Other than my mention of cvsnt and one other NOBODY is looking at it.
not to put _too_ fine a point on it:
CVSNT ELIMINATES THIS PROBLEM!!
Well, we have to look at TCO. Does CVSNT offer *other* compelling advantages over CVS *and* SVN? Because if it can't offer the other nice features of SVN, we have to weigh whether we want to switch to a one-trick pony or not. The impression I get from a quick glance is that CVSNT is just a tweaked CVS that adds a few things like smart merge and authentication. But Boost doesn't exactly have highly sensitive projects that require fine-grained security control, so it seems that it should be more concerned with the types of common user tasks that SVN does well in comparison to CVS. However, I am more than willing to be convinced otherwise, given additional information. Dave
At Monday 2005-02-07 00:35, you wrote:
Victor A. Wagner Jr. wrote:
At Sunday 2005-02-06 04:45, you wrote: [...] It's becoming apparent that the ONLY possibilities being considered are CVS (ancient history) and Subversion. Other than my mention of cvsnt and one other NOBODY is looking at it. not to put _too_ fine a point on it: CVSNT ELIMINATES THIS PROBLEM!!
Well, we have to look at TCO. Does CVSNT offer *other* compelling advantages over CVS *and* SVN? Because if it can't offer the other nice features of SVN, we have to weigh whether we want to switch to a one-trick pony or not. The impression I get from a quick glance is that CVSNT is just a tweaked CVS that adds a few things like smart merge and authentication.
cvs status -qq cvs ls I don't know what is considered "nice features"... cvsnt had a "move" for a while but it wasn't quite right and has been removed until it's fixed (soon, I hope since it's one of the more important things).
But Boost doesn't exactly have highly sensitive projects that require fine-grained security control, so it seems that it should be more concerned with the types of common user tasks that SVN does well in comparison to CVS.
what common tasks? personally I think we mishandle how we do things coming in to release, but since everyone else here seems to think that jerking the testers around makes sense I quit arguing. You can probably find an archive somewhere of my suggestions.
However, I am more than willing to be convinced otherwise, given additional information.
Dave
_______________________________________________ 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. wrote:
It's becoming apparent that the ONLY possibilities being considered are CVS (ancient history) and Subversion. Other than my mention of cvsnt and one other NOBODY is looking at it.
not to put _too_ fine a point on it:
CVSNT ELIMINATES THIS PROBLEM!!
And subversion will have this too: http://subversion.tigris.org/roadmap.html Russell
At 11:58 AM 2/6/2005, Victor A. Wagner Jr. wrote:
It's becoming apparent that the ONLY possibilities being considered are CVS (ancient history) and Subversion. Other than my mention of cvsnt and one
other NOBODY is looking at it.
Well, I've looked at it. CVSNT looks like it makes some improvements on CVS, but stays much more in the CVS mold than SVN. Whether that is good or bad depends on your point-of-view. Since CVSNT depends on regular CVS clients, my guess is that CVSNT is somewhat limited as to ability to introduce new approaches. I was initially very skeptical of SVN, but after using it I'm rapidly becoming convinced that by starting fresh they were able to provide more functionality yet greater ease-of-use. --Beman
Beman Dawes <bdawes@acm.org> writes:
At 11:58 AM 2/6/2005, Victor A. Wagner Jr. wrote:
It's becoming apparent that the ONLY possibilities being considered are CVS (ancient history) and Subversion. Other than my mention of cvsnt and one
other NOBODY is looking at it.
Well, I've looked at it. CVSNT looks like it makes some improvements on CVS, but stays much more in the CVS mold than SVN. Whether that is good or bad depends on your point-of-view. Since CVSNT depends on regular CVS clients, my guess is that CVSNT is somewhat limited as to ability to introduce new approaches.
CVSNT *works with* existing CVS clients, with some enhanced features. However, if you use a CVSNT client, then you get even more features. The website gives a full list at http://www.cvsnt.com/cvspro/compare.htm Here's a key list of those that I feel might apply to boost: Server LockServer provides file level locking More sophisticated / extra triggers available e.g. postcommit. Triggers also available via COM/DLL/.so interfaces Supports Unicode files with additional keyword expansion switches Efficient storage of binary files using binary deltas Extended modules functionality using the modules2 file Advanced Reserved Edits and checked commits (supercedes exclusive locking concept) Server-side default options (cvsrc) Client Smart Merge using MergePoint Supports Unicode files with additional keyword expansion switches "Import-and-go" by optionally turning freshly imported trees into a new sandbox automatically. No more need to purge and do a fresh checkout first Anthony -- Anthony Williams Software Developer
At Monday 2005-02-07 19:15, you wrote:
At 11:58 AM 2/6/2005, Victor A. Wagner Jr. wrote:
It's becoming apparent that the ONLY possibilities being considered are CVS (ancient history) and Subversion. Other than my mention of cvsnt and one other NOBODY is looking at it.
Well, I've looked at it. CVSNT looks like it makes some improvements on CVS, but stays much more in the CVS mold than SVN. Whether that is good or bad depends on your point-of-view. Since CVSNT depends on regular CVS clients, my guess is that CVSNT is somewhat limited as to ability to introduce new approaches.
well, I'm not sure how "regular" the client is, it's updated along with the server C:\Projects\boost>cvs ver Client: Concurrent Versions System (CVSNT) 2.0.62.1852 (client/server) Server: Concurrent Versions System (CVS) 1.11.16 (client/server) that's from my boost root directory.
I was initially very skeptical of SVN, but after using it I'm rapidly becoming convinced that by starting fresh they were able to provide more functionality yet greater ease-of-use.
I guess it's time for me to take another look at SVN. I've been "suffering" w/ the limitations of RCS/CVS since my Amiga days (though I _did_ get one enhancement pushed through back then). I picked up the docs on SVN about 2 years ago, and several of us looked at switching from VSS to it then, but chose cvs(NT) then (because we were going to be running on all windows systems) because the < 0.50 version just wouldn't do what we needed and we NEEDED to get off VSS.
--Beman
_______________________________________________ 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"
participants (22)
-
Alan Gutierrez -
Anthony Williams -
Beman Dawes -
Caleb Epstein -
Daniel Frey -
David Abrahams -
David B. Held -
Doug Gregor -
Edward Diener -
Gennadiy Rozental -
Jani Averbach -
Jeff Garland -
John Maddock -
Kevin Wheatley -
Martin Slater -
Michael van der Westhuizen -
Rene Rivera -
Robert Zeh -
Russell Hind -
troy d. straszheim -
Victor A. Wagner Jr. -
Walter Landry