Re: CVS and Subversion
On Mon, Jun 14, 2004 at 06:13:17PM +0200, Dirk-Willem van Gulik wrote: >... > Cause it actually lives on another machine than the repo (with > an ocean in between). We tried this however for the toy site > wleiden.webweaving.org:8080/svn/node-config/ (just 3.5Gb and > a few thousands commits sofar) and ran into too many puzzles; > like index.html; ensuring mod_perl did the right thing, etc. Though > I am sure it is possible. No, actually it isn't. Too many of the standard Apache modules (such as mod_autoindex and mod_dir) look directly into the filesystem. We need a "data store" mechanism in core Apache which those modules can use to query "filesystem-ish" properties. We've discussed this a number of times on the httpd developer list. mod_perl could be used to write some filters to apply to the SVN content, but some serious work in mod_perl (and possibly core apache) would be needed for SVN to serve up Perl scripts to mod_perl to execute to generate the content. mod_php can't integrate well; the PHP parser actually requires a handle onto the filesystem, so it isn't possible at this time to pick up scripts from arbitrary data stores. So... if you have anything beyond a basic site, you'd need to use Dirk's suggestion of an auto-checkout (heck, you need it simply for index.html). Eventually, we'll have better support in core Apache, but don't hold your breath until then. It might be a while :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS and Subversion
On Jun 14, 2004, at 6:04 PM, Stefano Mazzocchi wrote: Dirk-Willem van Gulik wrote: On Jun 11, 2004, at 10:35 PM, Stefano Mazzocchi wrote: Brian McCallister wrote: .. snipped subtle umask magic which needs to fit the ... operational culture of the community. .. good hint, thanks. As we had some conflicting requirements we pretty much killed all use of svn over ssh - and forced people to use HTTP/DAV (even on localhost). That solved 80% of those problems :-) can you elaborate more on this? [very interested] Eh not much to elaborate - by removing SSH and direct repo access/direct accounts - and only allowing a) svn through apache (and some backup scripts) the whole per-user umask, group access persm etc goes away - there is just the user ID of the web server and the uid of hte backup and that is it. (Though backup and recovery has a bit more perms than I like (and we get nice certificate based user mngt - which is really nice as you aint have to keep no stinking per user secrets). Dw - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS and Subversion
On Jun 14, 2004, at 6:02 PM, Stefano Mazzocchi wrote: Dirk-Willem van Gulik wrote: On Jun 11, 2004, at 2:20 PM, Henri Yandell wrote: 1) Website needs to be in SVN, else we'll still need accounts for everyone who wants to modify their site annd do releases. Are the SVN based projects taking an approach that handles this? Will it? In the company we right now use a small script, triggered by the commmit - which syncs the website up everytime a commit is made to the released branch/tag. curious, why not mod_proxy-it directly? Cause it actually lives on another machine than the repo (with an ocean in between). We tried this however for the toy site wleiden.webweaving.org:8080/svn/node-config/ (just 3.5Gb and a few thousands commits sofar) and ran into too many puzzles; like index.html; ensuring mod_perl did the right thing, etc. Though I am sure it is possible. Dw. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS and Subversion
Dirk-Willem van Gulik wrote: On Jun 11, 2004, at 10:35 PM, Stefano Mazzocchi wrote: Brian McCallister wrote: [EMAIL PROTECTED] mccallister]$ umask umask 0002 [EMAIL PROTECTED] mccallister]$ umask -S u=rwx,g=rwx,o=rx and set the group sticky bit on the repository home so that group is preserved good hint, thanks. As we had some conflicting requirements we pretty much killed all use of svn over ssh - and forced people to use HTTP/DAV (even on localhost). That solved 80% of those problems :-) can you elaborate more on this? [very interested] -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: CVS and Subversion
Dirk-Willem van Gulik wrote: On Jun 11, 2004, at 2:20 PM, Henri Yandell wrote: 1) Website needs to be in SVN, else we'll still need accounts for everyone who wants to modify their site annd do releases. Are the SVN based projects taking an approach that handles this? Will it? In the company we right now use a small script, triggered by the commmit - which syncs the website up everytime a commit is made to the released branch/tag. curious, why not mod_proxy-it directly? -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: CVS and Subversion
On Jun 14, 2004, at 8:37 AM, Ask Bjørn Hansen wrote: On Sat, 12 Jun 2004 00:45:31 +0900, Pier Fumagalli <[EMAIL PROTECTED]> wrote: That is when I started feeling that having all my history in big berkeley DB files which I could not "cat" was kinda scary... That's why the Subversion developers kindly gave us all sorts of ways to make backups: http://svnbook.red-bean.com/svnbook/book.html#svn-ch-5-sect-3.6 :-) Aye - and they (including CVS to massage them) have saved my ass on an almost monthly basis prior to 1.0.2. :-( Dw - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS and Subversion
On Sat, 12 Jun 2004 00:45:31 +0900, Pier Fumagalli <[EMAIL PROTECTED]> wrote: > That is when I started feeling that having all my history in big > berkeley DB files which I could not "cat" was kinda scary... That's why the Subversion developers kindly gave us all sorts of ways to make backups: http://svnbook.red-bean.com/svnbook/book.html#svn-ch-5-sect-3.6 :-) - ask - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS and Subversion
On Jun 11, 2004, at 5:33 PM, Brian W. Fitzpatrick wrote: On Fri, 2004-06-11 at 10:23, Niclas Hedhman wrote: On Friday 11 June 2004 18:17, Dirk-Willem van Gulik wrote: On a positive note; do look at subversion; play with it - and note that its modern infrastructure and standard based protocols do allow for levels of integration previously hard to attain. Another note that noone seems to consider, which I think is fairly important (read annoying); Subversion eats almost all CPU cycles on a 2.4 Linux Kernel, on updates and commits. Often so much that even the mouse is no longer tracking, and always making my entire desktop fairly unresponsive. And for Avalon that means ~1minute on my system (svn up)... Very interesting... I have never seen that behavior on my system, and I've worked with some pretty large repositories too... For what it is worth on good old Sparc 5 systems and FreeBSD on a normal 486 or a pentium; we're talking 1-2Mbyte of exec for CVS and checkout times in the order of a few minutes top's; with SVN we needed to increase the build partitions with some 50 Mbytes and a normal check out on these underspeced machines with SVN can easily take 30-45 minutes for a large tree (say apache, apr, tomcat, axis and some other bits from a local/private SVN repository). On something like a pentium 4 I've never noticed the difference. But those dated dinosaurs are not exactly the infrastructure's I would optimize the ASF's toolchain for. Dw - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS and Subversion
On Jun 11, 2004, at 3:29 PM, Henri Yandell wrote: I know of no uses cases for what you're describing... do you have one? Two of them. 1) Common for a piece of taggable code to inherit something outside of its .. 2) I suspect others do this differently, but I've often released things From the peanut gallery - We encounter those a lot as well esp. with code where some files in a release where certified by some outside agency or link to something higher up - like the meta makefiles. Dw - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS and Subversion
On Jun 11, 2004, at 2:20 PM, Henri Yandell wrote: 1) Website needs to be in SVN, else we'll still need accounts for everyone who wants to modify their site annd do releases. Are the SVN based projects taking an approach that handles this? Will it? In the company we right now use a small script, triggered by the commmit - which syncs the website up everytime a commit is made to the released branch/tag. Dw. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS and Subversion
On Jun 11, 2004, at 10:35 PM, Stefano Mazzocchi wrote: Brian McCallister wrote: [EMAIL PROTECTED] mccallister]$ umask umask 0002 [EMAIL PROTECTED] mccallister]$ umask -S u=rwx,g=rwx,o=rx and set the group sticky bit on the repository home so that group is preserved good hint, thanks. As we had some conflicting requirements we pretty much killed all use of svn over ssh - and forced people to use HTTP/DAV (even on localhost). That solved 80% of those problems :-) Dw - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS and Subversion
I second what Niclas said. It's a rare situation, but when it happens, it's a pain to recover (like, you press ^C because you regretted a commit but you end up regretting have pressed ^C due to the mess it caused :-) Felipe On Fri, 2004-06-11 at 12:11, Niclas Hedhman wrote: > On Friday 11 June 2004 21:02, Jim Moore wrote: > > Actually, the "all or nothing" part of the transaction isn't a big deal > > because, as you said, it's very rare that a commit in CVS would fail. > > But I often change my mind half way through... (lazy thought-loading), > Ctrl-C, > and CVS is 'half way through' . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS and Subversion
On Fri, 2004-06-11 at 17:43, James Duncan Davidson wrote: > On Jun 11, 2004, at 08:45, Pier Fumagalli wrote: > > > That is when I started feeling that having all my history in big > > berkeley DB files which I could not "cat" was kinda scary... > > Yeah, it's a bit scary for the largish project that I'm currently > setting up on SVN as well. But we're working around this by using a > derivative of hot-backup.py to keep multiple point-in-time backups of > the complete database around as well as dumps of the repository > alongside. In Subversion 1.1.0, you will be able to choose between BDB and new filesystem backend 'libsvn_fs_fs' that uses flat files to store all data. I suspect that a lot of people will prefer this option for smaller projects. > Disk is cheeeap. :) Amen, brother! -Fitz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS and Subversion
On Jun 11, 2004, at 08:45, Pier Fumagalli wrote: That is when I started feeling that having all my history in big berkeley DB files which I could not "cat" was kinda scary... Yeah, it's a bit scary for the largish project that I'm currently setting up on SVN as well. But we're working around this by using a derivative of hot-backup.py to keep multiple point-in-time backups of the complete database around as well as dumps of the repository alongside. Disk is cheeeap. :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS and Subversion
Brian McCallister wrote: [EMAIL PROTECTED] mccallister]$ umask umask 0002 [EMAIL PROTECTED] mccallister]$ umask -S u=rwx,g=rwx,o=rx and set the group sticky bit on the repository home so that group is preserved good hint, thanks. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: CVS and Subversion
[EMAIL PROTECTED] mccallister]$ umask umask 0002 [EMAIL PROTECTED] mccallister]$ umask -S u=rwx,g=rwx,o=rx and set the group sticky bit on the repository home so that group is preserved -Brian On Jun 11, 2004, at 3:00 PM, Stefano Mazzocchi wrote: Brian McCallister wrote: We hit this a number of times with svn+ssh until we got everyone to properly set their umask. haven't had it happen since then, however. uh, interesting, what umask did you use? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS and Subversion
Brian W. Fitzpatrick wrote: On Fri, 2004-06-11 at 13:15, Stefano Mazzocchi wrote: Pier Fumagalli wrote: On 11 Jun 2004, at 22:02, Jim Moore wrote: Actually, the "all or nothing" part of the transaction isn't a big deal because, as you said, it's very rare that a commit in CVS would fail. Problem being (though) is that I've seen Subversion (1.0.2 under Linux) fail right because of that... Somehow an "atomic" transaction was left open on the server, don't ask me why... Basically, after that commit failed, the entire repository was so slow that most TCP/IP connections were failing after 3 minutes for timeouts... Only solution was to run a "svn recover" followed by a "svn rmtxt" and again followed by another "svn recover"... I am experiencing random svn corruptions with svnserve over ssh with svn 1.0 Please be careful to distinguish "corruption" from "my repository needs to have 'svnadmin recover' run on it." Could you be running into a repository permissions error? http://subversion.tigris.org/project_faq.html#permissions (how do I find out the real version btw? why isn't svn -v|--version give me the version?) over linux 2.6.4 any clue? 'svn --version' works for me: $ svn --version svn, version 1.0.2 (r9423) compiled Apr 28 2004, 17:16:48 ... hit me with a baseball bat! -- Stefano, crawling back in his corner :-( smime.p7s Description: S/MIME Cryptographic Signature
Re: CVS and Subversion
Brian McCallister wrote: We hit this a number of times with svn+ssh until we got everyone to properly set their umask. haven't had it happen since then, however. uh, interesting, what umask did you use? -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: CVS and Subversion
We hit this a number of times with svn+ssh until we got everyone to properly set their umask. haven't had it happen since then, however. -Brian On Jun 11, 2004, at 2:15 PM, Stefano Mazzocchi wrote: Pier Fumagalli wrote: On 11 Jun 2004, at 22:02, Jim Moore wrote: Actually, the "all or nothing" part of the transaction isn't a big deal because, as you said, it's very rare that a commit in CVS would fail. Problem being (though) is that I've seen Subversion (1.0.2 under Linux) fail right because of that... Somehow an "atomic" transaction was left open on the server, don't ask me why... Basically, after that commit failed, the entire repository was so slow that most TCP/IP connections were failing after 3 minutes for timeouts... Only solution was to run a "svn recover" followed by a "svn rmtxt" and again followed by another "svn recover"... I am experiencing random svn corruptions with svnserve over ssh with svn 1.0 (how do I find out the real version btw? why isn't svn -v|--version give me the version?) over linux 2.6.4 any clue? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS and Subversion
On Fri, 2004-06-11 at 13:15, Stefano Mazzocchi wrote: > Pier Fumagalli wrote: > > > On 11 Jun 2004, at 22:02, Jim Moore wrote: > > > >> Actually, the "all or nothing" part of the transaction isn't a big deal > >> because, as you said, it's very rare that a commit in CVS would fail. > > > > > > Problem being (though) is that I've seen Subversion (1.0.2 under Linux) > > fail right because of that... Somehow an "atomic" transaction was left > > open on the server, don't ask me why... > > > > Basically, after that commit failed, the entire repository was so slow > > that most TCP/IP connections were failing after 3 minutes for timeouts... > > > > Only solution was to run a "svn recover" followed by a "svn rmtxt" and > > again followed by another "svn recover"... > > I am experiencing random svn corruptions with svnserve over ssh with svn > 1.0 Please be careful to distinguish "corruption" from "my repository needs to have 'svnadmin recover' run on it." Could you be running into a repository permissions error? http://subversion.tigris.org/project_faq.html#permissions > (how do I find out the real version btw? why isn't svn -v|--version > give me the version?) over linux 2.6.4 > > any clue? 'svn --version' works for me: $ svn --version svn, version 1.0.2 (r9423) compiled Apr 28 2004, 17:16:48 ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS and Subversion
Pier Fumagalli wrote: On 11 Jun 2004, at 22:02, Jim Moore wrote: Actually, the "all or nothing" part of the transaction isn't a big deal because, as you said, it's very rare that a commit in CVS would fail. Problem being (though) is that I've seen Subversion (1.0.2 under Linux) fail right because of that... Somehow an "atomic" transaction was left open on the server, don't ask me why... Basically, after that commit failed, the entire repository was so slow that most TCP/IP connections were failing after 3 minutes for timeouts... Only solution was to run a "svn recover" followed by a "svn rmtxt" and again followed by another "svn recover"... I am experiencing random svn corruptions with svnserve over ssh with svn 1.0 (how do I find out the real version btw? why isn't svn -v|--version give me the version?) over linux 2.6.4 any clue? -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: CVS and Subversion
On Friday 11 June 2004 23:23, Niclas Hedhman wrote: > Subversion eats almost all CPU cycles on a 2.4 Linux Kernel, on updates and > commits. Am I the only one who have this problem??? I am only using SVN CLI. [EMAIL PROTECTED] niclas]$ uname -a Linux f2.hedhman.org 2.4.20-20.9 #1 Mon Aug 18 11:45:58 EDT 2003 i686 i686 i386 GNU/Linux I have 2 ATA disks on the primary controller, and they are mirrored with SoftRAID. No other software I have, shows this type of lock-up, unless running out of RAM and thrashing starts, in fact SVN behaves exactly like thrashing came into the picture. Could that be the case??? I got 512MB and 'on a regular day' "top" would report something like; 01:56:59 up 2 days, 20:42, 13 users, load average: 2.05, 0.97, 0.79 101 processes: 94 sleeping, 7 running, 0 zombie, 0 stopped CPU states: 2.3% user 3.7% system 0.0% nice 0.0% iowait 93.8% idle Mem: 513852k av, 507388k used,6464k free, 0k shrd, 69212k buff 384884k actv,1200k in_d, 11024k in_c Swap: 1012072k av, 92016k used, 920056k free 212484k cached (sorry for the bad formatting) Which I interpret that 'cached memory' is plenty and will be released if necessary. Or does the intensive file reads (writes?) upset the Linux algorithm of 'cached' vs 'thrashed' memory? H Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS and Subversion
* Niclas Hedhman ([EMAIL PROTECTED]) wrote : > Another note that noone seems to consider, which I think is fairly important > (read annoying); > > Subversion eats almost all CPU cycles on a 2.4 Linux Kernel, on updates and > commits. Often so much that even the mouse is no longer tracking, and always > making my entire desktop fairly unresponsive. And for Avalon that means > ~1minute on my system (svn up)... > Sounds like you don't have DMA enabled for your disks. (I also have never seen this problem on a variety of machines) -Thom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS and Subversion
On 11 Jun 2004, at 22:02, Jim Moore wrote: Actually, the "all or nothing" part of the transaction isn't a big deal because, as you said, it's very rare that a commit in CVS would fail. Problem being (though) is that I've seen Subversion (1.0.2 under Linux) fail right because of that... Somehow an "atomic" transaction was left open on the server, don't ask me why... Basically, after that commit failed, the entire repository was so slow that most TCP/IP connections were failing after 3 minutes for timeouts... Only solution was to run a "svn recover" followed by a "svn rmtxt" and again followed by another "svn recover"... That is when I started feeling that having all my history in big berkeley DB files which I could not "cat" was kinda scary... But on the other hand, we (VNU, at work) are still using subversion because of all its other features (moving, copying, tag^H^H^Hbranch^H^H^H^H^Hcopying) and its quite impressive speed over slow/remote networks... Pier What is VERY cool about the atomic part is that all of your files in the commit are part of the same transaction. With CVS it's a very difficult to determine what files were committed together. Take a look at what the cvs-commit email program has to do in order to send out a single email for all the files you've committed to see an example, where it has to make a bunch of assumptions like "What other files have the same commit message?" and "Were they committed at the same time (give or take a few seconds)?" Reasonably intelligent changelog reports have the same problem, but they have to do that for every file. Fortunately there are (nasty) perl scripts for figuring that kind of thing out, but it's simply a non-issue with SVN. If you want to know what other files changed as part of rev 1234 you simply ask the server what other files were part of that transaction since it handles them all as one unit instead of bunches of seperate ones. (Another place it's nice is that if you have integration between your defect system and CVS you have to associate each file and rev back to the defect, whereas with SVN you only need to rev number as the files are implicit.) When I'm in "user" mode, I love the "move/rename keeps history" that Brian mentioned and don't really care about atomic/transactional commits. However, when I'm doing tools & project administration, that's when the transactions really rock. -Jim Moore - Original Message - From: "Vadim Gritsenko" <[EMAIL PROTECTED]> To: Sent: Friday, June 11, 2004 8:21 AM Subject: Re: CVS and Subversion Ceki Gülcü wrote: Heu.., a couple of questions from the totally ignorant (me). 1) what is an atomic commit? Do I need to wear a irradiation-protective suit to use it? "Atomic" as in "transaction" -- either all or nothing, should not crash in-between. I've not seen such crashes with CVS, but apparently other people encountered them. 2) How easy is it to migrate an existing CVS repo to subversion? infra has nifty scripts to convert everything including branches and history. Vadim Thanks in advance for your response, even if it is RTFM. At 01:04 PM 6/11/2004, Brian McCallister wrote: I think the best way to sell Subversion is "atomic commits" and "move/rename keeps history" (big seller to the Java "we love cheap rename in [Eclipse | IDEA | JDEE]" crowd) ;-) Now we just need to talk about adding dummy -dP flags to update so that I can stop getting errors... Did I mention "atomic commits" ? -Brian ps: atomic commits - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
Re: CVS and Subversion
On Fri, 2004-06-11 at 10:23, Niclas Hedhman wrote: > On Friday 11 June 2004 18:17, Dirk-Willem van Gulik wrote: > > > On a positive note; do look at subversion; play with it - and note that > > its modern infrastructure and standard based protocols do allow for > > levels of integration previously hard to attain. > > Another note that noone seems to consider, which I think is fairly important > (read annoying); > > Subversion eats almost all CPU cycles on a 2.4 Linux Kernel, on updates and > commits. Often so much that even the mouse is no longer tracking, and always > making my entire desktop fairly unresponsive. And for Avalon that means > ~1minute on my system (svn up)... Very interesting... I have never seen that behavior on my system, and I've worked with some pretty large repositories too... $ uname -a Linux pantheon 2.4.19-pre10 #2 SMP Mon Jun 24 09:49:16 CDT 2002 i686 GNU/Linux -Fitz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS and Subversion
On Jun 11, 2004, at 5:23 PM, Niclas Hedhman wrote: Subversion eats almost all CPU cycles on a 2.4 Linux Kernel, on updates and commits. Often so much that even the mouse is no longer tracking, and always making my entire desktop fairly unresponsive. And for Avalon that means ~1minute on my system (svn up)... Weird, I've been using SVN from almost a year, way before I switched, and never experienced/noticed that. Are you taking CLI subversion or some GUI on top of it? Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS and Subversion
On Friday 11 June 2004 18:17, Dirk-Willem van Gulik wrote: > On a positive note; do look at subversion; play with it - and note that > its modern infrastructure and standard based protocols do allow for > levels of integration previously hard to attain. Another note that noone seems to consider, which I think is fairly important (read annoying); Subversion eats almost all CPU cycles on a 2.4 Linux Kernel, on updates and commits. Often so much that even the mouse is no longer tracking, and always making my entire desktop fairly unresponsive. And for Avalon that means ~1minute on my system (svn up)... Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS and Subversion
On Friday 11 June 2004 21:02, Jim Moore wrote: > Actually, the "all or nothing" part of the transaction isn't a big deal > because, as you said, it's very rare that a commit in CVS would fail. But I often change my mind half way through... (lazy thought-loading), Ctrl-C, and CVS is 'half way through' . Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS and Subversion
On Fri, 2004-06-11 at 08:29, Henri Yandell wrote: > On Fri, 11 Jun 2004, Brian W. Fitzpatrick wrote: > > I know of no uses cases for what you're describing... do you have one? > > Two of them. > > 1) Common for a piece of taggable code to inherit something outside of its > directory, usually either a super-build.xml, or a super-project.xml. It's > hard to tag these when you tag the directory. This one is possible, but > quite a pain in SVN. I had to checkout just my releases/ directory, then > do manual copying. I suspect that it wasted diskspace on the server as it > wasn't url-url. Nope. If there are no content differences, the Subversion repository will do the most efficient thing and just copy the node (not the contents). > 2) I suspect others do this differently, but I've often released things > from Jakarta Commons where we've not included a certain directory or bunch > of files in the release because they're not ready yet. In this case, they > shouldn't be tagged with that release either. Fair enough. Those two cases are a bit difficult to manage in Subversion. > One option here might be to branch the code, then delete from the branch > the things you don't want. As branching and tagging seem to be the same > thing in SVN, I suspect this would work. Process change. Yes it would. > Yep. I suspect the solution is to modify the development process when it > has problems, but I think I heard something about subversion supporting a > property-tagging system at some point in the future that would work much > like CVS? This was 3rd hand information, and you'd know better :) No clue what this is about. Subversion does have the concept of per-node (file or directory) metadata, and per-revision metadata--they're called 'properties' and 'revision properties' respectively. See the section on Properties in the Subversion book: http://svnbook.red-bean.com/svnbook/ch07s02.html -Fitz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS and Subversion
On Fri, 2004-06-11 at 08:17, Brian McCallister wrote: > On Jun 11, 2004, at 8:21 AM, Vadim Gritsenko wrote: > >> 2) How easy is it to migrate an existing CVS repo to subversion? > > > > > > infra has nifty scripts to convert everything including branches and > > history. > > Subversion ships with a cvs2svn script which takes a long time to run, > but does a pretty good conversion job. I've spent the month of May substantially rewriting cvs2svn, and although I'm not done yet, it's already faster--especially on Really Large multi-gigabyte repositories. > We used it on a big, hairy, cvs > repository where I work and it performed flawlessly. Interestingly, it > attempts to atomize commits by assuming anything in a 5 minute window > is one commit. It's not quite that simple...multiple CVS revisions committed in the same 5 minute window *also* with the same author and the same log message are treated as as a single Subversion commit (with a few edge-case exceptions). -Fitz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS and Subversion
"atomic commits" is accurate -- the transactional part is a consequence of it. It's just that, in this case, the side-effect is cooler than the "primary" feature. But you're right in that it is different than most databases where you can't usually get to the transaction information once it's committed; in SVN the revision number is (effectively) the transaction id. In fact, what SVN stores is more a "transaction log" than anything. - Original Message - From: "Vadim Gritsenko" <[EMAIL PROTECTED]> To: Sent: Friday, June 11, 2004 9:17 AM Subject: Re: CVS and Subversion > Jim Moore wrote: > > >Actually, the "all or nothing" part of the transaction isn't a big deal > >because, as you said, it's very rare that a commit in CVS would fail. > > > >What is VERY cool about the atomic part is that all of your files in the > >commit are part of the same transaction. With CVS it's a very difficult to > >determine what files were committed together. Take a look at what the > >cvs-commit email program has to do in order to send out a single email for > >all the files you've committed to see an example, where it has to make a > >bunch of assumptions like "What other files have the same commit message?" > >and "Were they committed at the same time (give or take a few seconds)?" > >Reasonably intelligent changelog reports have the same problem, but they > >have to do that for every file. Fortunately there are (nasty) perl scripts > >for figuring that kind of thing out, but it's simply a non-issue with SVN. > >If you want to know what other files changed as part of rev 1234 you simply > >ask the server what other files were part of that transaction since it > >handles them all as one unit instead of bunches of seperate ones. (Another > >place it's nice is that if you have integration between your defect system > >and CVS you have to associate each file and rev back to the defect, whereas > >with SVN you only need to rev number as the files are implicit.) > > > >When I'm in "user" mode, I love the "move/rename keeps history" that Brian > >mentioned and don't really care about atomic/transactional commits. > >However, when I'm doing tools & project administration, that's when the > >transactions really rock. > > > > > > So, original mail ("atomic commits!") was misleading. It is really more > about "SVN stores transaction log", but not about "atomic commit". > Compare with databases, were transactions are atomic - but once > committed, there is no way (usually) to find out which records were > modified as part of transaction. > > Thanks for clarification. > > Vadim > > > >-Jim Moore - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS and Subversion
Jim Moore wrote: Actually, the "all or nothing" part of the transaction isn't a big deal because, as you said, it's very rare that a commit in CVS would fail. What is VERY cool about the atomic part is that all of your files in the commit are part of the same transaction. With CVS it's a very difficult to determine what files were committed together. Take a look at what the cvs-commit email program has to do in order to send out a single email for all the files you've committed to see an example, where it has to make a bunch of assumptions like "What other files have the same commit message?" and "Were they committed at the same time (give or take a few seconds)?" Reasonably intelligent changelog reports have the same problem, but they have to do that for every file. Fortunately there are (nasty) perl scripts for figuring that kind of thing out, but it's simply a non-issue with SVN. If you want to know what other files changed as part of rev 1234 you simply ask the server what other files were part of that transaction since it handles them all as one unit instead of bunches of seperate ones. (Another place it's nice is that if you have integration between your defect system and CVS you have to associate each file and rev back to the defect, whereas with SVN you only need to rev number as the files are implicit.) When I'm in "user" mode, I love the "move/rename keeps history" that Brian mentioned and don't really care about atomic/transactional commits. However, when I'm doing tools & project administration, that's when the transactions really rock. So, original mail ("atomic commits!") was misleading. It is really more about "SVN stores transaction log", but not about "atomic commit". Compare with databases, were transactions are atomic - but once committed, there is no way (usually) to find out which records were modified as part of transaction. Thanks for clarification. Vadim -Jim Moore ----- Original Message - From: "Vadim Gritsenko" <[EMAIL PROTECTED]> To: Sent: Friday, June 11, 2004 8:21 AM Subject: Re: CVS and Subversion Ceki Gülcü wrote: Heu.., a couple of questions from the totally ignorant (me). 1) what is an atomic commit? Do I need to wear a irradiation-protective suit to use it? "Atomic" as in "transaction" -- either all or nothing, should not crash in-between. I've not seen such crashes with CVS, but apparently other people encountered them. 2) How easy is it to migrate an existing CVS repo to subversion? infra has nifty scripts to convert everything including branches and history. Vadim Thanks in advance for your response, even if it is RTFM. At 01:04 PM 6/11/2004, Brian McCallister wrote: I think the best way to sell Subversion is "atomic commits" and "move/rename keeps history" (big seller to the Java "we love cheap rename in [Eclipse | IDEA | JDEE]" crowd) ;-) Now we just need to talk about adding dummy -dP flags to update so that I can stop getting errors... Did I mention "atomic commits" ? -Brian ps: atomic commits - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS and Subversion
On Fri, 11 Jun 2004, Brian W. Fitzpatrick wrote: > On Fri, 2004-06-11 at 07:20, Henri Yandell wrote: > > > 2) Tagging is clumsy. (I may just not be seeing it in the manual). It > > seems hard to tag a directory and files not in that directory with a tag, > > or tag a directory without tagging every file in it. > > Since a tag is essentially a 'copy' in Subversion, it is near impossible > to 'tag' a directory without tagging its contents (to do so, you would > have to copy the directory and then delete all of its contents). FWIW, > you can copy a single file into the tags directory--that's essentially > tagging a file, although it's not typically done that way. > > I know of no uses cases for what you're describing... do you have one? Two of them. 1) Common for a piece of taggable code to inherit something outside of its directory, usually either a super-build.xml, or a super-project.xml. It's hard to tag these when you tag the directory. This one is possible, but quite a pain in SVN. I had to checkout just my releases/ directory, then do manual copying. I suspect that it wasted diskspace on the server as it wasn't url-url. 2) I suspect others do this differently, but I've often released things from Jakarta Commons where we've not included a certain directory or bunch of files in the release because they're not ready yet. In this case, they shouldn't be tagged with that release either. One option here might be to branch the code, then delete from the branch the things you don't want. As branching and tagging seem to be the same thing in SVN, I suspect this would work. Process change. > Subversion has constant time O(1) tagging (copying). That means that > you can tag (copy) a tree containing 50,000 files in about 2 seconds.* Yep, speed is nice. Especially with lots of binaries in there, and the smaller space on the server too. > This is one of several areas that Subversion is different from CVS. Yep. I suspect the solution is to modify the development process when it has problems, but I think I heard something about subversion supporting a property-tagging system at some point in the future that would work much like CVS? This was 3rd hand information, and you'd know better :) I'm still a newbie to svn, but am generally finding svn a simple change on the client side. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS and Subversion
On Jun 11, 2004, at 8:21 AM, Vadim Gritsenko wrote: Ceki Gülcü wrote: Heu.., a couple of questions from the totally ignorant (me). 1) what is an atomic commit? Do I need to wear a irradiation-protective suit to use it? "Atomic" as in "transaction" -- either all or nothing, should not crash in-between. I've not seen such crashes with CVS, but apparently other people encountered them. I had meant that all of the changes checked in with a given commit are included in one "bunch." The commit can be rolled back as a whole instead of having to roll back each file (or rollback to a date, or tag). Basically like putting a cheap tag on every commit, automagically, which respects deletes, adds, moves in an expected manner. 2) How easy is it to migrate an existing CVS repo to subversion? infra has nifty scripts to convert everything including branches and history. Subversion ships with a cvs2svn script which takes a long time to run, but does a pretty good conversion job. We used it on a big, hairy, cvs repository where I work and it performed flawlessly. Interestingly, it attempts to atomize commits by assuming anything in a 5 minute window is one commit. -Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS and Subversion
Actually, the "all or nothing" part of the transaction isn't a big deal because, as you said, it's very rare that a commit in CVS would fail. What is VERY cool about the atomic part is that all of your files in the commit are part of the same transaction. With CVS it's a very difficult to determine what files were committed together. Take a look at what the cvs-commit email program has to do in order to send out a single email for all the files you've committed to see an example, where it has to make a bunch of assumptions like "What other files have the same commit message?" and "Were they committed at the same time (give or take a few seconds)?" Reasonably intelligent changelog reports have the same problem, but they have to do that for every file. Fortunately there are (nasty) perl scripts for figuring that kind of thing out, but it's simply a non-issue with SVN. If you want to know what other files changed as part of rev 1234 you simply ask the server what other files were part of that transaction since it handles them all as one unit instead of bunches of seperate ones. (Another place it's nice is that if you have integration between your defect system and CVS you have to associate each file and rev back to the defect, whereas with SVN you only need to rev number as the files are implicit.) When I'm in "user" mode, I love the "move/rename keeps history" that Brian mentioned and don't really care about atomic/transactional commits. However, when I'm doing tools & project administration, that's when the transactions really rock. -Jim Moore - Original Message ----- From: "Vadim Gritsenko" <[EMAIL PROTECTED]> To: Sent: Friday, June 11, 2004 8:21 AM Subject: Re: CVS and Subversion > Ceki Gülcü wrote: > > > Heu.., a couple of questions from the totally ignorant (me). > > > > 1) what is an atomic commit? Do I need to wear a > > irradiation-protective suit to use it? > > > "Atomic" as in "transaction" -- either all or nothing, should not crash > in-between. I've not seen such crashes with CVS, but apparently other > people encountered them. > > > > 2) How easy is it to migrate an existing CVS repo to subversion? > > > infra has nifty scripts to convert everything including branches and > history. > > Vadim > > > > Thanks in advance for your response, even if it is RTFM. > > > > At 01:04 PM 6/11/2004, Brian McCallister wrote: > > > >> I think the best way to sell Subversion is "atomic commits" and > >> "move/rename keeps history" (big seller to the Java "we love cheap > >> rename in [Eclipse | IDEA | JDEE]" crowd) ;-) > >> > >> Now we just need to talk about adding dummy -dP flags to update so > >> that I can stop getting errors... > >> > >> Did I mention "atomic commits" ? > >> > >> -Brian > >> > >> ps: atomic commits - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS and Subversion
On Fri, 2004-06-11 at 07:20, Henri Yandell wrote: > 2) Tagging is clumsy. (I may just not be seeing it in the manual). It > seems hard to tag a directory and files not in that directory with a tag, > or tag a directory without tagging every file in it. Since a tag is essentially a 'copy' in Subversion, it is near impossible to 'tag' a directory without tagging its contents (to do so, you would have to copy the directory and then delete all of its contents). FWIW, you can copy a single file into the tags directory--that's essentially tagging a file, although it's not typically done that way. I know of no uses cases for what you're describing... do you have one? Subversion has constant time O(1) tagging (copying). That means that you can tag (copy) a tree containing 50,000 files in about 2 seconds.* In CVS, that will take you somewhere in the neighborhood of 30 minutes since CVS's tagging is O(n). The same goes for branching. Oh and this copy only takes a tiny amount of space in the Subversion repository. * This is true of URL to URL copies only--if you copy a huge tree to another location in your working copy, of course, Subversion will have to take time to copy the files on your filesystem. This is one of several areas that Subversion is different from CVS. -Fitz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS and Subversion
Ceki Gülcü wrote: Heu.., a couple of questions from the totally ignorant (me). 1) what is an atomic commit? Do I need to wear a irradiation-protective suit to use it? "Atomic" as in "transaction" -- either all or nothing, should not crash in-between. I've not seen such crashes with CVS, but apparently other people encountered them. 2) How easy is it to migrate an existing CVS repo to subversion? infra has nifty scripts to convert everything including branches and history. Vadim Thanks in advance for your response, even if it is RTFM. At 01:04 PM 6/11/2004, Brian McCallister wrote: I think the best way to sell Subversion is "atomic commits" and "move/rename keeps history" (big seller to the Java "we love cheap rename in [Eclipse | IDEA | JDEE]" crowd) ;-) Now we just need to talk about adding dummy -dP flags to update so that I can stop getting errors... Did I mention "atomic commits" ? -Brian ps: atomic commits .. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS and Subversion
Two biggest problems I forsee with subversion: 1) Website needs to be in SVN, else we'll still need accounts for everyone who wants to modify their site annd do releases. Are the SVN based projects taking an approach that handles this? Will it? 2) Tagging is clumsy. (I may just not be seeing it in the manual). It seems hard to tag a directory and files not in that directory with a tag, or tag a directory without tagging every file in it. Otherwise I'm enjoying using subversion. I'm going to try having a structure of: /site/ /trunk/ /distributions/ /jar-repository/ and see if I can manage to not give out any accounts. Hen On Fri, 11 Jun 2004, Brian McCallister wrote: > I think the best way to sell Subversion is "atomic commits" and > "move/rename keeps history" (big seller to the Java "we love cheap > rename in [Eclipse | IDEA | JDEE]" crowd) ;-) > > Now we just need to talk about adding dummy -dP flags to update so that > I can stop getting errors... > > Did I mention "atomic commits" ? > > -Brian > > ps: atomic commits > > On Jun 11, 2004, at 6:17 AM, Dirk-Willem van Gulik wrote: > > > In reaction to some worried emails related to some projects moving > > from CVS to Subversion. > > > > -> Do not panic. > > > > -> There is no ASF driven push (yet) for this move, no deadlines, no > > forcing. > > > > -> It is you, the developers yourself, in each project who decide for > > -yourself- > > when and if it is time to go to Subversion - just let infrastructure > > know > > and they'll help you with the transition. > > > > -> But I urge you to give it a look - it is a darn cool piece of > > technology; and > > it integrates very nicely with other tools. > > > > And although it is true that Subversion is young and has a serious > > footprint - it does have > > one important feature for projects like the ASF: it no longer > > requires user accounts in order > > to do commits. So in theory it is easier to secure a box and guard > > against changes under the > > hood; i.e. done to the repository directly. And thus tamper with our > > record of history - as right > > now developers -must- have r/w access to disk with the repository > > itself on the CVS machine. > > With about a thousand committers using several thousands of machines > > back home and a > > ssh/password based access controls it is a given that things leak over > > time. And one leak is > > quite enough. > > > > Thus reducing history/repository access alone is something the ASF as > > the legal steward > > of the code cares about a lot. (Those who where around a few years > > back during the last > > compromise of the CVS machine may recall the countless hours of work > > when we had to > > pour over the CVS records and backups to certify each and every > > file). It also means that > > subversion is easier to sandbox - thus further minimizing the damage > > from 'real' exploits. > > > > So all in all - it is a step forward; but yes a relatively young step > > - and that is why we are > > not yet making this an ASF wide compulsory change. > > > > Secondly Ben Laurie/infrastructure is working on a ASF wide > > Certificate Authority in the > > Bunker.co.uk using a machine specially donated by > > Ironsystems.com/Cliff Skolnick. Once > > that is in place we've added an other much needed layer which allows > > us to continue to > > scale in numbers of developers without suddenly needing a dozen full > > time sysadmins :) > > and it allows us to decrease the sensitive information, like password > > files, which need > > to be managed on a daily basis by multiple people on the machines even > > more. > > > > And ultimately it means that it becomes more and more possible to rely > > less on a > > 'unix root' admin - and means that we can handle the mutations from > > the then several > > thousands of commtiters on a timely basis. > > > > So in sort - and to stress: there are no deadlines, pushing or sticks > > to get projects > > to move from CVS to Subversion. Just the above carrots. But unless the > > early projects > > hit some major snags with subversion - DO expect the ASF to move there > > in the next > > two or three years - to allow us to continue to scale the > > infrastructure along with the > > number of developers and their demands while being good stewards to > > our code > > heritage at the same time > > > > On a positive note; do look at subversion; play with it - and note > > that its modern > > infrastructure and standard based protocols do allow for levels of > > integration > > previously hard to attain. > > > > Thanks, > > > > Dw, > > -- > > Dirk-Willem van Gulik, President of the Apache Software Foundation. > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PRO
Re: CVS and Subversion
Heu.., a couple of questions from the totally ignorant (me). 1) what is an atomic commit? Do I need to wear a irradiation-protective suit to use it? 2) How easy is it to migrate an existing CVS repo to subversion? Thanks in advance for your response, even if it is RTFM. At 01:04 PM 6/11/2004, Brian McCallister wrote: I think the best way to sell Subversion is "atomic commits" and "move/rename keeps history" (big seller to the Java "we love cheap rename in [Eclipse | IDEA | JDEE]" crowd) ;-) Now we just need to talk about adding dummy -dP flags to update so that I can stop getting errors... Did I mention "atomic commits" ? -Brian ps: atomic commits On Jun 11, 2004, at 6:17 AM, Dirk-Willem van Gulik wrote: In reaction to some worried emails related to some projects moving from CVS to Subversion. -> Do not panic. -> There is no ASF driven push (yet) for this move, no deadlines, no forcing. -> It is you, the developers yourself, in each project who decide for -yourself- when and if it is time to go to Subversion - just let infrastructure know and they'll help you with the transition. -> But I urge you to give it a look - it is a darn cool piece of technology; and it integrates very nicely with other tools. And although it is true that Subversion is young and has a serious footprint - it does have one important feature for projects like the ASF: it no longer requires user accounts in order to do commits. So in theory it is easier to secure a box and guard against changes under the hood; i.e. done to the repository directly. And thus tamper with our record of history - as right now developers -must- have r/w access to disk with the repository itself on the CVS machine. With about a thousand committers using several thousands of machines back home and a ssh/password based access controls it is a given that things leak over time. And one leak is quite enough. Thus reducing history/repository access alone is something the ASF as the legal steward of the code cares about a lot. (Those who where around a few years back during the last compromise of the CVS machine may recall the countless hours of work when we had to pour over the CVS records and backups to certify each and every file). It also means that subversion is easier to sandbox - thus further minimizing the damage from 'real' exploits. So all in all - it is a step forward; but yes a relatively young step - and that is why we are not yet making this an ASF wide compulsory change. Secondly Ben Laurie/infrastructure is working on a ASF wide Certificate Authority in the Bunker.co.uk using a machine specially donated by Ironsystems.com/Cliff Skolnick. Once that is in place we've added an other much needed layer which allows us to continue to scale in numbers of developers without suddenly needing a dozen full time sysadmins :) and it allows us to decrease the sensitive information, like password files, which need to be managed on a daily basis by multiple people on the machines even more. And ultimately it means that it becomes more and more possible to rely less on a 'unix root' admin - and means that we can handle the mutations from the then several thousands of commtiters on a timely basis. So in sort - and to stress: there are no deadlines, pushing or sticks to get projects to move from CVS to Subversion. Just the above carrots. But unless the early projects hit some major snags with subversion - DO expect the ASF to move there in the next two or three years - to allow us to continue to scale the infrastructure along with the number of developers and their demands while being good stewards to our code heritage at the same time On a positive note; do look at subversion; play with it - and note that its modern infrastructure and standard based protocols do allow for levels of integration previously hard to attain. Thanks, Dw, -- Dirk-Willem van Gulik, President of the Apache Software Foundation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ceki Gülcü For log4j documentation consider "The complete log4j manual" ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS and Subversion
I think the best way to sell Subversion is "atomic commits" and "move/rename keeps history" (big seller to the Java "we love cheap rename in [Eclipse | IDEA | JDEE]" crowd) ;-) Now we just need to talk about adding dummy -dP flags to update so that I can stop getting errors... Did I mention "atomic commits" ? -Brian ps: atomic commits On Jun 11, 2004, at 6:17 AM, Dirk-Willem van Gulik wrote: In reaction to some worried emails related to some projects moving from CVS to Subversion. -> Do not panic. -> There is no ASF driven push (yet) for this move, no deadlines, no forcing. -> It is you, the developers yourself, in each project who decide for -yourself- when and if it is time to go to Subversion - just let infrastructure know and they'll help you with the transition. -> But I urge you to give it a look - it is a darn cool piece of technology; and it integrates very nicely with other tools. And although it is true that Subversion is young and has a serious footprint - it does have one important feature for projects like the ASF: it no longer requires user accounts in order to do commits. So in theory it is easier to secure a box and guard against changes under the hood; i.e. done to the repository directly. And thus tamper with our record of history - as right now developers -must- have r/w access to disk with the repository itself on the CVS machine. With about a thousand committers using several thousands of machines back home and a ssh/password based access controls it is a given that things leak over time. And one leak is quite enough. Thus reducing history/repository access alone is something the ASF as the legal steward of the code cares about a lot. (Those who where around a few years back during the last compromise of the CVS machine may recall the countless hours of work when we had to pour over the CVS records and backups to certify each and every file). It also means that subversion is easier to sandbox - thus further minimizing the damage from 'real' exploits. So all in all - it is a step forward; but yes a relatively young step - and that is why we are not yet making this an ASF wide compulsory change. Secondly Ben Laurie/infrastructure is working on a ASF wide Certificate Authority in the Bunker.co.uk using a machine specially donated by Ironsystems.com/Cliff Skolnick. Once that is in place we've added an other much needed layer which allows us to continue to scale in numbers of developers without suddenly needing a dozen full time sysadmins :) and it allows us to decrease the sensitive information, like password files, which need to be managed on a daily basis by multiple people on the machines even more. And ultimately it means that it becomes more and more possible to rely less on a 'unix root' admin - and means that we can handle the mutations from the then several thousands of commtiters on a timely basis. So in sort - and to stress: there are no deadlines, pushing or sticks to get projects to move from CVS to Subversion. Just the above carrots. But unless the early projects hit some major snags with subversion - DO expect the ASF to move there in the next two or three years - to allow us to continue to scale the infrastructure along with the number of developers and their demands while being good stewards to our code heritage at the same time On a positive note; do look at subversion; play with it - and note that its modern infrastructure and standard based protocols do allow for levels of integration previously hard to attain. Thanks, Dw, -- Dirk-Willem van Gulik, President of the Apache Software Foundation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CVS and Subversion
In reaction to some worried emails related to some projects moving from CVS to Subversion. -> Do not panic. -> There is no ASF driven push (yet) for this move, no deadlines, no forcing. -> It is you, the developers yourself, in each project who decide for -yourself- when and if it is time to go to Subversion - just let infrastructure know and they'll help you with the transition. -> But I urge you to give it a look - it is a darn cool piece of technology; and it integrates very nicely with other tools. And although it is true that Subversion is young and has a serious footprint - it does have one important feature for projects like the ASF: it no longer requires user accounts in order to do commits. So in theory it is easier to secure a box and guard against changes under the hood; i.e. done to the repository directly. And thus tamper with our record of history - as right now developers -must- have r/w access to disk with the repository itself on the CVS machine. With about a thousand committers using several thousands of machines back home and a ssh/password based access controls it is a given that things leak over time. And one leak is quite enough. Thus reducing history/repository access alone is something the ASF as the legal steward of the code cares about a lot. (Those who where around a few years back during the last compromise of the CVS machine may recall the countless hours of work when we had to pour over the CVS records and backups to certify each and every file). It also means that subversion is easier to sandbox - thus further minimizing the damage from 'real' exploits. So all in all - it is a step forward; but yes a relatively young step - and that is why we are not yet making this an ASF wide compulsory change. Secondly Ben Laurie/infrastructure is working on a ASF wide Certificate Authority in the Bunker.co.uk using a machine specially donated by Ironsystems.com/Cliff Skolnick. Once that is in place we've added an other much needed layer which allows us to continue to scale in numbers of developers without suddenly needing a dozen full time sysadmins :) and it allows us to decrease the sensitive information, like password files, which need to be managed on a daily basis by multiple people on the machines even more. And ultimately it means that it becomes more and more possible to rely less on a 'unix root' admin - and means that we can handle the mutations from the then several thousands of commtiters on a timely basis. So in sort - and to stress: there are no deadlines, pushing or sticks to get projects to move from CVS to Subversion. Just the above carrots. But unless the early projects hit some major snags with subversion - DO expect the ASF to move there in the next two or three years - to allow us to continue to scale the infrastructure along with the number of developers and their demands while being good stewards to our code heritage at the same time On a positive note; do look at subversion; play with it - and note that its modern infrastructure and standard based protocols do allow for levels of integration previously hard to attain. Thanks, Dw, -- Dirk-Willem van Gulik, President of the Apache Software Foundation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]