Repository access and cvs watch
Hi, AFAICT there is currently no way to make cvs provide writable files when checking out/updating the boost repository. This causes me some grief and I might not be the only one out there. After reading the CVS manual (well the watch part) I have concluded that this is due to the fact that somebody issued a recursive 'cvs watch on' on the boost tree. AFAICS this has not been discussed on the mailing list. This forces a certain usage of cvs on everybody else. I.e. the users have to use 'cvs edit' (or fiddle with file permissions). For now I am strongly opposed to this way of using cvs. In my experience the use of 'cvs edit' does not provide significant benefit while it adds significant overhead to my work. Most users will change the permissions locally and not bother with cvs edit anyway. If there is anybody out there who has different experiences I would be very interested to hear about them. I therefore propose to turn cvs watch off thus giving the user a choice whether she wants read-only or read-write files. Please note that this does not disable the watching of files in general. Every user still can use cvs watch add to watch files and is still guaranteed to get notified about the really interesting events (i.e. those that alter a file in the repository). What did I miss? What do you think? Thomas
On 8/30/05, Thomas Witt <witt@acm.org> wrote:
AFAICT there is currently no way to make cvs provide writable files when checking out/updating the boost repository. This causes me some grief and I might not be the only one out there.
Are you using cvs on the command line, or a GUI? WinCVS for example (and probably its brethren), defaults to checking out readonly. Its in the globals I think (not at my dev machine at the moment)
Thomas Matelich wrote:
On 8/30/05, Thomas Witt <witt@acm.org> wrote:
Are you using cvs on the command line, or a GUI? WinCVS for example (and probably its brethren), defaults to checking out readonly. Its in the globals I think (not at my dev machine at the moment)
I am using the commandline and cvs -w does not cut it either. And no I don't have CVSREAD set. But yes there still might be something I missed. Thomas
Thomas Witt <witt@acm.org> writes:
Thomas Matelich wrote:
On 8/30/05, Thomas Witt <witt@acm.org> wrote:
Are you using cvs on the command line, or a GUI? WinCVS for example (and probably its brethren), defaults to checking out readonly. Its in the globals I think (not at my dev machine at the moment)
I am using the commandline and cvs -w does not cut it either. And no I don't have CVSREAD set. But yes there still might be something I missed.
You might look in the docs to see if there's something that can be set in your .cvsrc to change this. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Thomas Witt <witt@acm.org> writes:
Thomas Matelich wrote:
On 8/30/05, Thomas Witt <witt@acm.org> wrote:
Are you using cvs on the command line, or a GUI? WinCVS for example (and probably its brethren), defaults to checking out readonly. Its in the globals I think (not at my dev machine at the moment)
I am using the commandline and cvs -w does not cut it either. And no I don't have CVSREAD set. But yes there still might be something I missed.
You might look in the docs to see if there's something that can be set in your .cvsrc to change this.
I did try this, without success. Also, note that only few files in Boost have watches on them, so this should not matter either. But, I recall there were plans to switch to Subversion, which does not have such problems (in addition to being vastly better that CVS in other respect). What happened to those plans? - Volodya
On Wed, Aug 31, 2005 at 03:21:50PM +0400, Vladimir Prus wrote:
But, I recall there were plans to switch to Subversion, which does not have such problems (in addition to being vastly better that CVS in other respect). What happened to those plans?
oh! this would be a very nice feature :) -----[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Vladimir Prus <ghost@cs.msu.su> writes:
David Abrahams wrote:
Thomas Witt <witt@acm.org> writes:
Thomas Matelich wrote:
On 8/30/05, Thomas Witt <witt@acm.org> wrote:
Are you using cvs on the command line, or a GUI? WinCVS for example (and probably its brethren), defaults to checking out readonly. Its in the globals I think (not at my dev machine at the moment)
I am using the commandline and cvs -w does not cut it either. And no I don't have CVSREAD set. But yes there still might be something I missed.
You might look in the docs to see if there's something that can be set in your .cvsrc to change this.
I did try this, without success. Also, note that only few files in Boost have watches on them, so this should not matter either.
But, I recall there were plans to switch to Subversion, which does not have such problems (in addition to being vastly better that CVS in other respect). What happened to those plans?
Definitely on hold until after 1.33.1 -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
I did try this, without success. Also, note that only few files in Boost have watches on them, so this should not matter either.
But, I recall there were plans to switch to Subversion, which does not have such problems (in addition to being vastly better that CVS in other respect). What happened to those plans?
Definitely on hold until after 1.33.1
Do you mean that the switch won't happen until then, or that no work will be done until then. Some things like installing server are rather independent. If that done, given that CVS->SVN was successfully done in past, switch will require just a day to convert current state and load it into the server. - Volodya
On Aug 31, 2005, at 9:33 AM, Vladimir Prus wrote:
David Abrahams wrote:
I did try this, without success. Also, note that only few files in Boost have watches on them, so this should not matter either.
But, I recall there were plans to switch to Subversion, which does not have such problems (in addition to being vastly better that CVS in other respect). What happened to those plans?
Definitely on hold until after 1.33.1
Do you mean that the switch won't happen until then, or that no work will be done until then. Some things like installing server are rather independent. If that done, given that CVS->SVN was successfully done in past, switch will require just a day to convert current state and load it into the server.
I think I somehow ended up as the person to handle the switchover, which means that *nothing* will happen until after 1.33.1 because I'm way too overloaded. What needs to happen? Several things: - Decide how to layout the SVN repository - Decide if we should use the fine-grained access controls Subversion allows, and who gets what kind of access - Decide if we should jettison some old junk (long-dead branches, etc.) from CVS, and what that junk is - Update the various web pages and HOWTOs to reference Subversion, tools such as TortoiseSVN, etc. OSL is willing to host the Boost Subversion repository. We already have a Subversion server for all of our internal projects and all of the computing power and bandwidth that we would need. Doug
Doug Gregor wrote:
On Aug 31, 2005, at 9:33 AM, Vladimir Prus wrote:
David Abrahams wrote:
I did try this, without success. Also, note that only few files in Boost have watches on them, so this should not matter either.
But, I recall there were plans to switch to Subversion, which does not have such problems (in addition to being vastly better that CVS in other respect). What happened to those plans?
Definitely on hold until after 1.33.1
Do you mean that the switch won't happen until then, or that no work will be done until then. Some things like installing server are rather independent. If that done, given that CVS->SVN was successfully done in past, switch will require just a day to convert current state and load it into the server.
I think I somehow ended up as the person to handle the switchover, which means that *nothing* will happen until after 1.33.1 because I'm way too overloaded.
Ok, I see.
What needs to happen? Several things:
- Decide how to layout the SVN repository
Well, I though that's pretty standard ("/trunk + /branches + /tag"), but you decide.
- Decide if we should use the fine-grained access controls Subversion allows, and who gets what kind of access
Why bother? You can retroactively restrict access for anybody.
- Decide if we should jettison some old junk (long-dead branches, etc.) from CVS, and what that junk is
Why bother? This can be done after conversion.
- Update the various web pages and HOWTOs to reference Subversion, tools such as TortoiseSVN, etc.
Ah.. that's some work indeed.
OSL is willing to host the Boost Subversion repository. We already have a Subversion server for all of our internal projects and all of the computing power and bandwidth that we would need.
Good to hear! - Volodya
On Thu, 01 Sep 2005 10:03:20 +0400, Vladimir Prus wrote
OSL is willing to host the Boost Subversion repository. We already have a Subversion server for all of our internal projects and all of the computing power and bandwidth that we would need.
Good to hear!
As I think we've discussed before, we need to plan a significant time for this conversion. I'd say 30 days as a minimum conversion period to allow everyone time to get/learn the new tools etc. Yes, several of us did some testing in Jan when we discussed this last, but that was hardly everyone. I'd say we need a 'conversion manager' to work out a detailed schedule and manage the process of setting up a beta repository for experimentation, etc. I'd suggest we add what we started... http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Subversion_Co... Finally, I'm not sure we addressed all the concerns with subversion. As I recall there was discussion about large increases in the diskspace required, etc. Personally I think it's the way to go, but I'd think we need to get broader agreement first. Jeff
Jeff Garland wrote:
On Thu, 01 Sep 2005 10:03:20 +0400, Vladimir Prus wrote
OSL is willing to host the Boost Subversion repository. We already have a Subversion server for all of our internal projects and all of the computing power and bandwidth that we would need.
Good to hear!
As I think we've discussed before, we need to plan a significant time for this conversion. I'd say 30 days as a minimum conversion period to allow everyone time to get/learn the new tools etc. Yes, several of us did some testing in Jan when we discussed this last, but that was hardly everyone. I'd say we need a 'conversion manager' to work out a detailed schedule and manage the process of setting up a beta repository for experimentation, etc.
I believe you're overly cautions. Take as example the biggest project ever switched to Subversion -- KDE. There were no real problems after the switch. As user interface of Subversion is almost the same as in CVS. GUI clients is the only issue I see. - Volodya
On Thu, 01 Sep 2005 18:17:02 +0400, Vladimir Prus wrote
Jeff Garland wrote:
I believe you're overly cautions.
Perhaps. I'm just suggesting that we step back, plan out the steps, and give everyone enough time to get used to the new world. Instead of being overly optimistic (as is typical in our release schedules that drag on forever) we should be more realistic with this conversion.
Take as example the biggest project ever switched to Subversion -- KDE. There were no real problems after the switch. As user interface of Subversion is almost the same as in CVS.
So what, how much effort went into the run-up to the switchover? As I said, I think subversion is the way to go, but realize this needs to be fit in with the release schedule, the upgrade to boost V2, reviews, revamp of the web site, etc, etc. Bottom line is that this will temporarily delay other things and we just need to do it with our eyes open -- that is, with a plan. For example, we might plan to do this right after 1.34 (behind the build.v2 upgrade) and then we have time to do whatever needs to be done -- instead of just rushing to do it right now... Jeff
Jeff Garland wrote:
Take as example the biggest project ever switched to Subversion -- KDE. There were no real problems after the switch. As user interface of Subversion is almost the same as in CVS.
So what, how much effort went into the run-up to the switchover?
Quite some, but most of that effort was spent to speeding up the coversion process, and cleaning up branches. For Boost, this should be not a problem, due to much smaller repository and smaller number of branches and simpler branch structure. - Volodya
On 9/2/05, Vladimir Prus <ghost@cs.msu.su> wrote:
Jeff Garland wrote:
Take as example the biggest project ever switched to Subversion -- KDE. There were no real problems after the switch. As user interface of Subversion is almost the same as in CVS.
So what, how much effort went into the run-up to the switchover?
Quite some, but most of that effort was spent to speeding up the coversion process, and cleaning up branches.
For Boost, this should be not a problem, due to much smaller repository and smaller number of branches and simpler branch structure.
And I would recommend against cleaning up any branches based on my experience with cvs2svn. It can become confused by the deletion of tags (and possibly old branch revisions - not sure) and will end up generating a too-large Subversion repository as a result (10:1 size increase in my pathological case). It is better to leave everything in there, and remove unwanted branches/tags from the converted Subversion repository ex post facto. -- Caleb Epstein caleb dot epstein at gmail dot com
On 9/1/05, Jeff Garland <jeff@crystalclearsoftware.com> wrote: Finally, I'm not sure we addressed all the concerns with subversion. As I
recall there was discussion about large increases in the diskspace required, etc. Personally I think it's the way to go, but I'd think we need to get broader agreement first.
Just a data point in the disk-space argument. I've done some conversions of decent-sized CVS repositories and the Subversion repository did not use that much more disk space than CVS did. It ended up being about 1:1 SVN:CVS ratio in terms of disk space usage, maybe slightly higher but not a lot. I manage to create a massively large Subversion repository (~10:1 size increase) when converting a CVS repository that had been pruned of old tags (cvs tag -d). The branches-without-tags confused cvs2svn and caused it to generate very many "unnamed" branches that chewed up a ton of disk space. Excluding those branches where the old tags had been removed fixed this problem. I think the GCC folks and other groups who have very large CVS repositories (multi-gigabyte) have had similar results. -- Caleb Epstein caleb dot epstein at gmail dot com
Caleb Epstein wrote:
On 9/1/05, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
Finally, I'm not sure we addressed all the concerns with subversion. As I
recall there was discussion about large increases in the diskspace required, etc. Personally I think it's the way to go, but I'd think we need to get broader agreement first.
Just a data point in the disk-space argument. I've done some conversions of decent-sized CVS repositories and the Subversion repository did not use that much more disk space than CVS did. It ended up being about 1:1 SVN:CVS ratio in terms of disk space usage, maybe slightly higher but not a lot.
I believe the issue that is being talked about here is the required space for the checked-out tree, not the repository, as subversion keeps a copy of the original files in the source tree to enable more operations being performed offline. Regards, Stefan
Jeff Garland wrote:
On Thu, 01 Sep 2005 10:03:20 +0400, Vladimir Prus wrote
OSL is willing to host the Boost Subversion repository. We already have a Subversion server for all of our internal projects and all of the computing power and bandwidth that we would need.
Good to hear!
As I think we've discussed before, we need to plan a significant time for this conversion. I'd say 30 days as a minimum conversion period to allow everyone time to get/learn the new tools etc. Yes, several of us did some testing in Jan when we discussed this last, but that was hardly everyone. I'd say we need a 'conversion manager' to work out a detailed schedule and manage the process of setting up a beta repository for experimentation, etc.
I just noticed my webserver is getting hits on /svn/boost, thought I'd check in and see where this discussion had gone... Having done the conversion once, I'll volunteer to do it again. Most efficient way forward, seems to me, is to start doing them and beating on them. Next question would be how OSL wants to go forward. -t
Vladimir Prus <ghost@cs.msu.su> writes:
Doug Gregor wrote:
What needs to happen? Several things:
- Decide how to layout the SVN repository
Well, I though that's pretty standard ("/trunk + /branches + /tag"), but you decide.
It can be much more complicated when there are multiple sub-projects with their own private branches. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 9/1/05, David Abrahams <dave@boost-consulting.com> wrote:
It can be much more complicated when there are multiple sub-projects with their own private branches
How so? What about something like (apropos of another thread): branches/ threads-tng/ boost/ config/ detail/ thread/ etc... libs/ thread/ In other words, a branch would copy those portions of the trunk/ hierarchy that they change and/or that they require to compile. Or am I missing something? -- Caleb Epstein caleb dot epstein at gmail dot com
Vladimir Prus <ghost@cs.msu.su> writes:
David Abrahams wrote:
I did try this, without success. Also, note that only few files in Boost have watches on them, so this should not matter either.
But, I recall there were plans to switch to Subversion, which does not have such problems (in addition to being vastly better that CVS in other respect). What happened to those plans?
Definitely on hold until after 1.33.1
Do you mean that the switch won't happen until then, or that no work will be done until then.
I don't know. But given that OSL (mostly Doug) is managing the SVN change and the release of 1.33.1, I wouldn't count on anything until after 1.33.1 -- Dave Abrahams Boost Consulting www.boost-consulting.com
Hi, to be honest, I am unsure whether SVN fits the boost development model any better than CVS does, and propose to look at using git/cogito instead. Boost mainly consists of a set of "subsystems", which each have their respective maintainers, and only a few "glue" files that are mainly touched by the release managers. IMO, it would make sense to express this in the repository structure by having each subsystem maintained in a separate branch, and the "master" repository updated from these branches when they are fit for inclusion (similar to the Linux development model). Besides that, git has the IMO very valuable separation between commits and pushes, that is, you can commit single changes offline and only synchronize to the next upstream repository when there is a network connection, which may be of great help for some developers. Simon
On Thu, 01 Sep 2005 14:37:45 +0200, Simon Richter wrote
Hi,
...
Boost mainly consists of a set of "subsystems", which each have their respective maintainers, and only a few "glue" files that are mainly touched by the release managers.
Not true. Various developers often contribute changes into a whole range of common files and across the tree. This includes things like config changes affecting multiple libs, web pages, etc.
IMO, it would make sense to express this in the repository structure by having each subsystem maintained in a separate branch, and the "master" repository updated from these branches when they are fit for inclusion (similar to the Linux development model).
This still might make sense to evaluate, but not b/c of the point above... Jeff
Simon Richter wrote:
Hi,
to be honest, I am unsure whether SVN fits the boost development model any better than CVS does, and propose to look at using git/cogito instead.
Boost mainly consists of a set of "subsystems", which each have their respective maintainers, and only a few "glue" files that are mainly touched by the release managers. IMO, it would make sense to express this in the repository structure by having each subsystem maintained in a separate branch, and the "master" repository updated from these branches when they are fit for inclusion (similar to the Linux development model).
I don't see what problems that will solve.
Besides that, git has the IMO very valuable separation between commits and pushes, that is, you can commit single changes offline and only synchronize to the next upstream repository when there is a network connection, which may be of great help for some developers.
I think it was already decided to use Subversion. Well, I realize that these days everybody writes code while on plane ;-), but it's still better to switch to the most mature CVS replacement, rather than start arguing if git, one of 3 (or is that 4) variants of arch, or monotone, or darcs or whatever else is best solution for on-plane development. - Volodya
Vladimir Prus wrote:
I think it was already decided to use Subversion. Well, I realize that these days everybody writes code while on plane ;-), but it's still better to switch to the most mature CVS replacement, rather than start arguing if git, one of 3 (or is that 4) variants of arch, or monotone, or darcs or whatever else is best solution for on-plane development. There is svk (http://svk.elixus.org/) - it's a distributed version control system built on top of Subversion.
It can be used to mirror [parts of] remote repository and to create "offline branches" for personal expirements. Svk also supports advanced star-merge algorithm for merge-tracking and usually works much faster than svn. And the best part: svk is a pure client-side application and it requires no modifications to SVN server. -- With respect, Alex Besogonov(cyberax@elewise.com)
On Sep 1, 2005, at 7:37 AM, Simon Richter wrote:
to be honest, I am unsure whether SVN fits the boost development model any better than CVS does, and propose to look at using git/cogito instead.
OSL is only offering to host a Subversion repository. Any proposal to use anything other than Subversion will also need to specify who is going to host the repository. I'm not saying this to shut out other options, but there are economics at work. We use Subversion on a daily basis with many projects, so hosting yet another Subversion repository requires very little effort. However, we do not have the resources to configure and maintain a server for another revision control system. Doug
Doug Gregor wrote:
OSL is only offering to host a Subversion repository. Any proposal to use anything other than Subversion will also need to specify who is going to host the repository.
I am not a boost developer, I only use boost so I don't know exactly how much traffic there is to the boost CVS, but most distributed SCM systems can use dumb servers. For example, darcs can use HTTP for public access and SSH for developers and even supports simply sending changesets by email and so on. Likewise, git supports http/ftp/rsync and probably others. Also, distributed SCMs can be mirrored very easily (rsync), so the load can be balanced very easily even from a slow main machine. Most of them only require a lot of traffic when first checking out or cloning a repository, after then the load is minimal. I would suggest that the boost developers look at darcs. LL
On Sep 2, 2005, at 6:10 AM, Lexington Luthor wrote:
Doug Gregor wrote:
OSL is only offering to host a Subversion repository. Any proposal to use anything other than Subversion will also need to specify who is going to host the repository.
I am not a boost developer, I only use boost so I don't know exactly how much traffic there is to the boost CVS, but most distributed SCM systems can use dumb servers. For example, darcs can use HTTP for public access and SSH for developers and even supports simply sending changesets by email and so on. Likewise, git supports http/ftp/rsync and probably others.
Someone needs to maintain the software on those dumb servers. At this risk of sounding rude, this is not a point for discussion. OSL will host a Subversion repository, only. To propose any other SCM tool, we (Boost) need to know who is going to host it, because that matters almost as much as the tool itself from a reliability standpoint.
Also, distributed SCMs can be mirrored very easily (rsync), so the load can be balanced very easily even from a slow main machine.
This is not a concern. Doug
Simon Richter wrote:
Hi,
to be honest, I am unsure whether SVN fits the boost development model any better than CVS does, and propose to look at using git/cogito instead.
Git/cogito is too new, I doubt anybody uses that except the Linux kernel folks.
Besides that, git has the IMO very valuable separation between commits and pushes, that is, you can commit single changes offline and only synchronize to the next upstream repository when there is a network connection, which may be of great help for some developers.
Have you looked at SVK? It can complement Subversion nicely. With the Subversion/SVK combination you can get the benefits of both centralized and distributed version control - whichever suits you most. I.e. there is a centralized Subversion repository, but each developer can mirror it locally with SVK and work offline, synchronizing with the master repository from time to time.
Simon Richter <Simon.Richter@hogyros.de> wrote:
Hi,
to be honest, I am unsure whether SVN fits the boost development model any better than CVS does, and propose to look at using git/cogito instead.
For all of the distributed version control systems, you will still need a central server. You need a place where people can get the latest version. So it almost doesn't matter what the format of the central repository is, because you can always (lossly) translate to whatever your native format is. That is what projects like Tailor [1] do. In terms of what the format for the central repository should be, Subversion is not a terrible choice. It doesn't really track renames, it doesn't like to be interrupted, etc., but it is reasonably fast and secure. Cheers, Walter [1] http://www.darcs.net/DarcsWiki/Tailor
David Abrahams wrote:
Thomas Witt <witt@acm.org> writes:
You might look in the docs to see if there's something that can be set in your .cvsrc to change this.
I did look in the docs and I tried different settings (.cvsrc + commandline). As far as I can tell there is nothing that can change this. Thomas
participants (16)
-
Alex Besogonov -
Caleb Epstein -
David Abrahams -
Domenico Andreoli -
Doug Gregor -
Douglas Gregor -
Jeff Garland -
Lexington Luthor -
Peter Petrov -
Simon Richter -
Stefan Seefeld -
Thomas Matelich -
Thomas Witt -
troy d. straszheim -
Vladimir Prus -
Walter Landry