A little patch to add Wx::GenericDirCtrl. A non-native control (on OS X at least) but maybe useful to someone. I have tested it but think it should just be added to controls.rb sample - will do later when i have fixed some other probs with that. Also, I''ve started putting class-specifc style constants in the relevant .i file, as discussed previosuly - will submit a patch doing this for existing classes down the line. Lastly have added a page to the wiki showing class support by category - looks a lot better for wxruby2 done this way, shows how much of the core GUI api we support now. http://wxruby.rubyforge.org/wiki/wiki.pl?ClassesSupportedByCategory cheers alex _______________________________________________ wxruby-users mailing list wxruby-users@rubyforge.org http://rubyforge.org/mailman/listinfo/wxruby-users
Alex Fenton wrote:> Lastly have added a page to the wiki showing class support by category > - looks a lot better for wxruby2 done this way, shows how much of the > core GUI api we support now. > > http://wxruby.rubyforge.org/wiki/wiki.pl?ClassesSupportedByCategory >Very nice. Good work, Alex. Roy
Good stuff Alex. Now we just need to get one of the admins to add all these changes to the CVS HEAD so we do not step on each others changes. I want to do some more work on wxRuby but am worried that I will change stuff that was changed in an uncommitted patch and any subsequent patches will not work once the HEAD is updated (I had this problem in the past and is a pain to deal with). Kevin, Nick or Curt you guys out there? We need an active maintainer on this project to move it forward and I personally think it should be Alex or Roy at the moment. Sean On 8/1/06, Roy Sutton <roys at mindspring.com> wrote:> Alex Fenton wrote: > > Lastly have added a page to the wiki showing class support by category > > - looks a lot better for wxruby2 done this way, shows how much of the > > core GUI api we support now. > > > > http://wxruby.rubyforge.org/wiki/wiki.pl?ClassesSupportedByCategory > > > Very nice. Good work, Alex. > > Roy > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users >
Alex, The wiki page is very well done, nice job! Now we have a good place to look for tasks that need to be done. Sean
On Tue, 2006-08-01 at 15:25 -0700, Sean Long wrote:> Good stuff Alex. > > Now we just need to get one of the admins to add all these changes to > the CVS HEAD so we do not step on each others changes. > > I want to do some more work on wxRuby but am worried that I will > change stuff that was changed in an uncommitted patch and any > subsequent patches will not work once the HEAD is updated (I had this > problem in the past and is a pain to deal with). > > Kevin, Nick or Curt you guys out there? > > We need an active maintainer on this project to move it forward and I > personally think it should be Alex or Roy at the moment.I''m here...sort of. I keep hoping to find several hours to devote to wxruby, but it keeps not happening. Recently, I haven''t even been keeping up with my email. I would be fine with Alex and/or Roy directly updating CVS at this point. The last thing I want to be is a bottleneck. Hopefully I can become more active again when things quiet down here. Alex and Roy: Do you want CVS rights? Curt and others: Any objections? Everyone: Bzr is still my favorite distributed version control system. If we were using it, it would be much easier for many people to contribute code, and the project would be far less dependent on any one person (like me). Is there any interest yet in moving in that direction? Kevin
> I''m here...sort of. I keep hoping to find several hours to devote to > wxruby, but it keeps not happening. Recently, I haven''t even been > keeping up with my email.In a few weeks my wife is due to have our second child and I will probably vanish off the radar as well.> Everyone: Bzr is still my favorite distributed version control system. > If we were using it, it would be much easier for many people to > contribute code, and the project would be far less dependent on any one > person (like me). Is there any interest yet in moving in that > direction? >I am installing it as I write this and it has gotten a lot farther than Darcs on Intel based Mac''s, the ghc compiler still does not work on the x86 Mac. After reading the mini intro to Bazaar I think it sounds pretty slick, the push feature looks nice and is something I would probably do with my branch. The mini intro is here: http://bazaar-vcs.org/QuickHackingWithBzr The bazaar web site is designed well and easy to find info on, bonus points for that. Do you have a test repo setup anywhere that I can play with? Sean
While looking into bazaar I found this: http://bazaar-vcs.org/BzrForeignBranches/Subversion?action=show&redirect=BzrSvn Which allows Bazaar to interact with a Subversion repo as if it was a Bazaar branch. So we could just move from CVS to SVN (which is straight forward) and people can pull from SVN for the latest HEAD and us developers could use Bazaar for development work. Sean On 8/1/06, Sean Long <sean.m.long at gmail.com> wrote:> > I''m here...sort of. I keep hoping to find several hours to devote to > > wxruby, but it keeps not happening. Recently, I haven''t even been > > keeping up with my email. > > In a few weeks my wife is due to have our second child and I will > probably vanish off the radar as well. > > > Everyone: Bzr is still my favorite distributed version control system. > > If we were using it, it would be much easier for many people to > > contribute code, and the project would be far less dependent on any one > > person (like me). Is there any interest yet in moving in that > > direction? > > > > I am installing it as I write this and it has gotten a lot farther > than Darcs on Intel based Mac''s, the ghc compiler still does not work > on the x86 Mac. > > After reading the mini intro to Bazaar I think it sounds pretty slick, > the push feature looks nice and is something I would probably do with > my branch. The mini intro is here: > http://bazaar-vcs.org/QuickHackingWithBzr > > The bazaar web site is designed well and easy to find info on, bonus > points for that. > > Do you have a test repo setup anywhere that I can play with? > > Sean >
Hi all Thanks for bringing this up Sean.> I would be fine with Alex and/or Roy directly updating CVS at this > point. The last thing I want to be is a bottleneck. Hopefully I can > become more active again when things quiet down here. >First up, I think Kevin has been doing a great job as maintainer. People here might remember that he came out of Wx::Retirement to move the project forward. But if his time''s limited, perhaps routine tending of the CVS tree isn''t the best way to use it. I would rather use his extensive experience and knowledge of wxruby to guide big decisions, and tackle tricky probs and help out on the GTK version where poss.> Alex and Roy: Do you want CVS rights? > > Curt and others: Any objections? >I am not keen to start committing core SWIG stuff to the CVS tree without someone else reviewing. Such interface files as I''ve submitted have been developed by imitation and doggedness rather than any real understanding of hte C++ type system, memory mgmt or SWIg. Plus I think on principle we should try .i patches on at least two platforms before committing. So, is anyone willing and able to review and commit patches to the SWIG stuff? I have a bit more skill in writing english docs and ruby code and I wonder if I should spend more time on this now. It might be useful to have CVS rights so that I can commit docs and low-risk tweaks to samples. As mentioned before, I''m also up for helping to manage bugs and releases if that seems helpful. I suggest that we throw out a binary release based on the tree pretty much as it is now - I''ll put this in a separate email.> Everyone: Bzr is still my favorite distributed version control system. > If we were using it, it would be much easier for many people to > contribute code, and the project would be far less dependent on any one > person (like me). Is there any interest yet in moving in that > direction? >I''m a bit lazy about learning new dev tools eg RCS. But I''m up for learning bzr if it would help - I sometimes have to check out a fresh tree and copy changes to keep my patches clean. But presumably we still have to have one core tree? Also, I think we do benefit from the rubyforge hosting of our RCS system - eg viewcvs, statcvs, SSH. Bear in mind that someone might need to host and maintain this for a bzr repository. Thanks alex
I''m going to echo Alex''s sentiments here. I''m quite up to my eyeballs at the moment, too. I would be happy to pitch in and commit changes. But I''m much happier committing someone else''s changes than my own. As long as we have two sets of eyes on each change I think anyone can do the commits. I haven''t played with Bzr either but I can do whatever. It''s just more bytes on the hard drive as far as I''m concerned. Roy Alex Fenton wrote:> Hi all > > Thanks for bringing this up Sean. > >> I would be fine with Alex and/or Roy directly updating CVS at this >> point. The last thing I want to be is a bottleneck. Hopefully I can >> become more active again when things quiet down here. >> >> > First up, I think Kevin has been doing a great job as maintainer. People > here might remember that he came out of Wx::Retirement to move the > project forward. But if his time''s limited, perhaps routine tending of > the CVS tree isn''t the best way to use it. I would rather use his > extensive experience and knowledge of wxruby to guide big decisions, and > tackle tricky probs and help out on the GTK version where poss. > >> Alex and Roy: Do you want CVS rights? >> >> Curt and others: Any objections? >> >> > I am not keen to start committing core SWIG stuff to the CVS tree > without someone else reviewing. Such interface files as I''ve submitted > have been developed by imitation and doggedness rather than any real > understanding of hte C++ type system, memory mgmt or SWIg. Plus I think > on principle we should try .i patches on at least two platforms before > committing. > > So, is anyone willing and able to review and commit patches to the SWIG > stuff? > > I have a bit more skill in writing english docs and ruby code and I > wonder if I should spend more time on this now. It might be useful to > have CVS rights so that I can commit docs and low-risk tweaks to samples. > > As mentioned before, I''m also up for helping to manage bugs and releases > if that seems helpful. I suggest that we throw out a binary release > based on the tree pretty much as it is now - I''ll put this in a separate > email. > >> Everyone: Bzr is still my favorite distributed version control system. >> If we were using it, it would be much easier for many people to >> contribute code, and the project would be far less dependent on any one >> person (like me). Is there any interest yet in moving in that >> direction? >> >> > I''m a bit lazy about learning new dev tools eg RCS. But I''m up for > learning bzr if it would help - I sometimes have to check out a fresh > tree and copy changes to keep my patches clean. But presumably we still > have to have one core tree? Also, I think we do benefit from the > rubyforge hosting of our RCS system - eg viewcvs, statcvs, SSH. Bear in > mind that someone might need to host and maintain this for a bzr repository. > > Thanks > alex > > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > >
Thanks for all the feedback, guys. Aside from time shortages, we seem to have two big problems: 1. We want to have some kind of code review system before patches end up in the "official" tree 2. We don''t want patches to "rot" while awaiting review and integration I don''t think we can accomplish those goals with CVS. We might be able to meet these goals with SVN, but I have never used SVN myself, so I''m not sure. I could imagine each contributor having his own branch within the SVN repository. Patches could presumably be pulled and merged between branches. The official maintainer would pull patches into the official branch. As I have said before, I much prefer the philosophy of distributed systems like bzr. In such a system, each contributor would have their own branch(es), and patches could be easily pulled between branches. Hopefully bzr has some nice tools for reviewing patches...but I''m not sure they''re any better (or even as good as) those available for CVS or SVN. But here''s the twist: I really want to try bzr on a real project. So I would be willing to commit more time to the project if one of the side benefits was learning bzr. I can also offer bzr repo hosting for any developer who doesn''t have a suitable server account for publishing their own wxruby branch. (I believe any web hosting account with ssh, sftp, or webdav would work). Some combination of SVN and bzr would be fine with me, if it offers benefits to non-bzr users. I would propose that any switch happen immediately after the proposed "alpha" release. Kevin On Wed, 2006-08-02 at 16:04 -0400, Roy Sutton wrote:> I''m going to echo Alex''s sentiments here. I''m quite up to my eyeballs > at the moment, too. I would be happy to pitch in and commit changes. > But I''m much happier committing someone else''s changes than my own. As > long as we have two sets of eyes on each change I think anyone can do > the commits. > > I haven''t played with Bzr either but I can do whatever. It''s just more > bytes on the hard drive as far as I''m concerned. > > Roy > > Alex Fenton wrote: > > Hi all > > > > Thanks for bringing this up Sean. > > > >> I would be fine with Alex and/or Roy directly updating CVS at this > >> point. The last thing I want to be is a bottleneck. Hopefully I can > >> become more active again when things quiet down here. > >> > >> > > First up, I think Kevin has been doing a great job as maintainer. People > > here might remember that he came out of Wx::Retirement to move the > > project forward. But if his time''s limited, perhaps routine tending of > > the CVS tree isn''t the best way to use it. I would rather use his > > extensive experience and knowledge of wxruby to guide big decisions, and > > tackle tricky probs and help out on the GTK version where poss. > > > >> Alex and Roy: Do you want CVS rights? > >> > >> Curt and others: Any objections? > >> > >> > > I am not keen to start committing core SWIG stuff to the CVS tree > > without someone else reviewing. Such interface files as I''ve submitted > > have been developed by imitation and doggedness rather than any real > > understanding of hte C++ type system, memory mgmt or SWIg. Plus I think > > on principle we should try .i patches on at least two platforms before > > committing. > > > > So, is anyone willing and able to review and commit patches to the SWIG > > stuff? > > > > I have a bit more skill in writing english docs and ruby code and I > > wonder if I should spend more time on this now. It might be useful to > > have CVS rights so that I can commit docs and low-risk tweaks to samples. > > > > As mentioned before, I''m also up for helping to manage bugs and releases > > if that seems helpful. I suggest that we throw out a binary release > > based on the tree pretty much as it is now - I''ll put this in a separate > > email. > > > >> Everyone: Bzr is still my favorite distributed version control system. > >> If we were using it, it would be much easier for many people to > >> contribute code, and the project would be far less dependent on any one > >> person (like me). Is there any interest yet in moving in that > >> direction? > >> > >> > > I''m a bit lazy about learning new dev tools eg RCS. But I''m up for > > learning bzr if it would help - I sometimes have to check out a fresh > > tree and copy changes to keep my patches clean. But presumably we still > > have to have one core tree? Also, I think we do benefit from the > > rubyforge hosting of our RCS system - eg viewcvs, statcvs, SSH. Bear in > > mind that someone might need to host and maintain this for a bzr repository. > > > > Thanks > > alex > > > > > > > > _______________________________________________ > > wxruby-users mailing list > > wxruby-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wxruby-users > > > > > > > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users
Hi> 1. We want to have some kind of code review system before patches end up > in the "official" tree >I think Roy and I want to have ''core'' SWIG patches reviewed before check-in, but are happy for now to do this for one another''s and other''s patches, coming from other platforms. Is that accurate? That sounds viable.> 2. We don''t want patches to "rot" while awaiting review and integration >Given the rate we generate changes, I think we''re OK if we can check in changes within 3-4 days. Again, sounds doable?> I don''t think we can accomplish those goals with CVS. >I think we can maybe get close. As you say SVN might help with (2) with separate developer branches but I''ve never used it either.> As I have said before, I much prefer the philosophy of distributed > systems like bzr.I think I like the philosophy better - but it''s about philosophy and pragmatism.> Hopefully bzr has some nice tools for reviewing patches...but I''m not > sure they''re any better (or even as good as) those available for CVS or > SVN. >This is one concern - there are lots of mature tools for working with CVS & SVN - integration with IDEs, viewers, loggers, GUIs etc. bzr looks promising (there is bzr-mode.el!) but I''m guessing it doesn''t have all that yet.> But here''s the twist: I really want to try bzr on a real project. So I > would be willing to commit more time to the project if one of the side > benefits was learning bzr.That''s a generous offer, thank you.> I can also offer bzr repo hosting for any > developer who doesn''t have a suitable server account for publishing > their own wxruby branch. (I believe any web hosting account with ssh, > sftp, or webdav would work). >Erk! Does this mean that you have to publish to a web-server to share changes??> Some combination of SVN and bzr would be fine with me, if it offers > benefits to non-bzr users. >This is really my biggest concern. One of the things we want to do with an alpha release is attract developers. Because we''ve all been working on the project for a while, I think we forget the entry barriers are already fairly high for a casual Ruby-centric developer: SWIG (no, not THAT version, THIS version), WxWidgets (no, compiled like THIS, not like THAT). Choosing an esoteric (though promising) RCS system is adding another barrier to potential developers. There doesn''t look to be a bog-standard OS X binary dmg available (install Fink first...). And I also think that a mainstream RCS plus rubyforge hosting at the moment gives us a better guarantee of project continuity through developer changes etc. Sorry if this sounds negative. I just we are perhaps better for now (at least until we have a stable wxruby2) to look at human/organisational rather than technical solutions to the problem, as outlined above, rather than having a cutting-edge RCS to contend with/assist us. But I''m happy to give it a whirl if everyone else is keen and thinks it will help - especially if we think we can enable participation via SVN too. cheers alex
> I think Roy and I want to have ''core'' SWIG patches reviewed before > check-in, but are happy for now to do this for one another''s and other''s > patches, coming from other platforms. Is that accurate? That sounds viable.Sounds like a good idea to me, I do 95% of my work on Mac OS X so I only occasionally compile a new wxRuby for Windows. The compile time is the biggest drag for me testing on Windows more often. I have thought about making a rake task called ''make'' so you would run: rake make which would create a Makefile and compile from that so then we can use the -j 2 command line parameter for multiple processor machines (which both of my Mac systems are). If Ruby supported hardware threads I could just thread the rake tasks. Anyway this is something to do down the road.> > 2. We don''t want patches to "rot" while awaiting review and integration > > > Given the rate we generate changes, I think we''re OK if we can check in > changes within 3-4 days. Again, sounds doable?That sounds like a reasonable time frame to me. I would be happy with less than 7 days.> > I don''t think we can accomplish those goals with CVS. > > > I think we can maybe get close. As you say SVN might help with (2) with > separate developer branches but I''ve never used it either.Think of SVN as CVS++, I converted my projects to SVN from CVS and kept on chugging along with minimal changes to the workflow. My experience is only with one man projects so I am not sure how the separate branches would work, it seams to me that it would be similar to how bzr works but only for the privileged few not the masses.> This is one concern - there are lots of mature tools for working with > CVS & SVN - integration with IDEs, viewers, loggers, GUIs etc. bzr looks > promising (there is bzr-mode.el!) but I''m guessing it doesn''t have all > that yet.I think we should look at moving to SVN and use bzr on top of that so our investment in bzr will not be a waste if it does not work out because we still have an up-to-date SVN repo.> Erk! Does this mean that you have to publish to a web-server to share > changes??You can still make patches and send them to someone else to merge with their branch or the official branch (at least that is how Darcs works and bzr seems similar).> This is really my biggest concern. One of the things we want to do with > an alpha release is attract developers.I think this is another good reason to move to SVN, I feel that developers think more highly of projects that use SVN over CVS. KDE last year changed over to SVN from CVS and I have not heard any horror stories about it. You can read about the KDE switch here: http://dot.kde.org/1115285369/> There doesn''t look to be a bog-standard > OS X binary dmg available (install Fink first...)I personally prefer DarwinPorts but we could host pre-compiled versions for the big 3 platforms. Sean
Thanks Daniel, Kevin & Sean for helpful info on SVN and bzr. I had a look at the subversion website today and seems nice. Plus like you say, Sean, subversion seems to be cool at the moment making CVS look lame like sensible school shoes ;) I suggest we proceed with the following for the time being: - ask Tom @ Rubyforge to convert our repo from CVS to svn as soon as we release wxruby2 alpha1. - keep a close eye on how commits process etc are working, and try out bzr on top of svn. - plan to have a reviewer for commits to the swig/ and rake/ parts of the tree, or major changes elsewhere. - Roy, me, Kevin (where poss), Curt (where poss) committers to trunk - we continue to use the m.l. to let each other know about major work underway Also, I think Daniel made a good point about not being afraid to commit (!). After all, part of the reason for using a RCS is to enable backing-out of disastrous changes. Hope this sounds like a reasonable way forward. cheers alex
On Thu, 2006-08-03 at 19:04 +0100, Alex Fenton wrote:> I suggest we proceed with the following for the time being: > - ask Tom @ Rubyforge to convert our repo from CVS to svn as soon as we > release wxruby2 alpha1. > - keep a close eye on how commits process etc are working, and try out > bzr on top of svn. > - plan to have a reviewer for commits to the swig/ and rake/ parts of > the tree, or major changes elsewhere. > - Roy, me, Kevin (where poss), Curt (where poss) committers to trunk > - we continue to use the m.l. to let each other know about major work > underwaySounds good.> > Also, I think Daniel made a good point about not being afraid to commit > (!). After all, part of the reason for using a RCS is to enable > backing-out of disastrous changes.With cvs, I don''t quite agree. With svn or bzr, I think that''s right. The big difference is that cvs thinks in individual files, whereas the other two think in "changesets". With changesets, it''s easy to see everything that was checked in as a unit, and to revert an entire checkin. Kevin
On Thu, 2006-08-03 at 06:09 +0100, Alex Fenton wrote:> This is one concern - there are lots of mature tools for working with > CVS & SVN - integration with IDEs, viewers, loggers, GUIs etc. bzr looks > promising (there is bzr-mode.el!) but I''m guessing it doesn''t have all > that yet.The only cvs-related tool I use for the wxruby project is meld (a diff/merge utility for gnome), and it has bzr support. I would be interested to know what cvs-related tools and capabilities folks on this list actually use now and would hate to give up. Oh, and bzr has much better online source browsing capabilities than cvs. I guess a related question is: What editor/IDE do each of you use to work on wxruby? I use anjuta, which is ok but not great. I''ll probably try FreeRIDE again. Hmmm. A bzr plugin would be cool!> Erk! Does this mean that you have to publish to a web-server to share > changes??No, but it is a common way is to do so. One of the reasons I like bzr is that publishing your own repo doesn''t require a shell account, nor any special code on the server. The requirements are quite easy to fulfill, unlike most other distributed RCS systems. Another way, as mentioned, is to circulate patches via email. A third way is for the project to set up a central server that people with permission can push patches to. This mode resembles the cvs/svn model, but "outsiders" can still have full version control on their local computers, and can merge the latest from the central server at any time.> Choosing an esoteric (though promising) RCS system is adding another > barrier to potential developers. There doesn''t look to be a bog-standard > OS X binary dmg available (install Fink first...). And I also think that > a mainstream RCS plus rubyforge hosting at the moment gives us a better > guarantee of project continuity through developer changes etc.I remain unconvinced by this argument, but fully accept that I could be wrong. I suspect the ability of people to contribute code without first being "approved" for cvs/svn permissions would offset the difficulty of getting bzr set up. At this point, I expect only motivated developers to really work on wxruby.> Sorry if this sounds negative. I just we are perhaps better for now (at > least until we have a stable wxruby2) to look at human/organisational > rather than technical solutions to the problem, as outlined above, > rather than having a cutting-edge RCS to contend with/assist us.Well, as I said, I consider it a huge human issue that people cannot effectively participate in the process until after they have contributed enough loose patches to earn a spot on the cvs/svn server.> But I''m > happy to give it a whirl if everyone else is keen and thinks it will > help - especially if we think we can enable participation via SVN too.Similarly, I''m not yet willing to push hard on this issue. I believe that at some point, perhaps within a year or two, distributed RCS will be the default and obvious choice for a project like this. At this point, it''s still a bit of a risk. Kevin
--- Alex Fenton <alex at pressure.to> wrote:> Thanks Daniel, Kevin & Sean for helpful info on SVN and bzr. I had a > look at the subversion website today and seems nice. Plus like you say, > Sean, subversion seems to be cool at the moment making CVS look lame > like sensible school shoes ;) > > I suggest we proceed with the following for the time being: > - ask Tom @ Rubyforge to convert our repo from CVS to svn as soon as we > release wxruby2 alpha1. > [snip]{lurk mode off} Regarding cvs, svn, and bzr; I had a look around a couple weeks ago as I was considering the same sort of decision with my own projects. I found out a few things: It seems that the "free software" folks tend to often choose cvs (which is GPL''d v2 or later, though it''s not an official GNU project) while open source folks often choose Subversion (which is released under an "Apache/BSD-style" license). The svn guys make it explicit that they want to "take over the CVS user base" (see the first item in their faq: "Why does this project exist?"). This rubs some folks in the free software community the wrong way, and I think there''s been some backlash lately and even a resurgence of interest in cvs. cvs recently got a new maintainer (a skilled guy who used to write a lot of articles in C/C++ user''s journal), and the manual is now hosted by Ximbiot (http://ximbiot.com/) which offers cvs support (among other services I figure). Also, I suspect cvs may have more of a "community project" flavor, while svn seems to have been a concerted effort (at least early on) primarily by the good folks at Tigris. (I haven''t looked at who''s doing commits though, so I could be off-base here.) Also, cvs seems to be a simpler, more unixy design (i.e. relying on file permissions, last-modified dates, and so forth), whereas svn is larger and more sophisticated (offering binary diffs, atomic commits, versioned symlinks, it''s own virtual "versioned filesystem"...). Though I don''t know any real details about the internals of either one. Another thing about svn is that its developers seem amply concerned with it being able to run well on MS Windows. svn makes use of a middle-layer library called "apache portable runtime". I checked http://apr.apache.org/ but found no tutorial docs on using APR, which in my book is a red flag to me to stay away. I see that Apache httpd uses APR but not many other projects currently are (http://apr.apache.org/projects.html). Regarding bzr, I think it started originally from TLA (Tom Lord''s Arch), but then grew into being it''s own from-scratch rewrite in Python. It''s GPL''d and has associations with Ubuntu and Canonical. It''s lead dev is Martin Pool. (His name looked familiar to me, then I remembered that he wrote PikiPiki -- a nice simple wiki in Python). Incidentally, on Marti''s blog (http://sourcefrog.net/weblog), there''s mention on the front page about bzr-svn integration, so that functionality might not be too far off... Personally, I like cvs well enough because it''s well-worn, familiar (for the basic stuff I currently use it for anyhow), and reliable, but if I was going to switch to something, bzr really seems to have a lot going for it: great web site, great docs, written in a modern HLL (I know, I know: unfortunately not Ruby ;) ), very active community, GPL''d, and I really like the idea of a decentralized version control system (though I can''t say that I fully understand the mechanics of it yet). So, in sum, I''d suggest that bzr actually has a frostier cool-factor than svn. :) Just my 2 cents. {re-enable lurk mode} ---John __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
> I would be > interested to know what cvs-related tools and capabilities folks on this > list actually use now and would hate to give up.I only use cvs for wxRuby now so I just use the cvs command line program. On svn I also only use the command line program. I do use the FileMerge visual diff viewer that comes with the Mac OS X dev. tools quite a bit.> I guess a related question is: What editor/IDE do each of you use to > work on wxruby?I use TextMate as my editor, as you can see from the above cvs tools question I like simple tools.> I believe that at some point, perhaps within a year or two, distributed RCS will > be the default and obvious choice for a project like this.You are probably right. Sean
> On Thu, 2006-08-03 at 19:04 +0100, Alex Fenton wrote: > > I suggest we proceed with the following for the time being: > > - ask Tom @ Rubyforge to convert our repo from CVS to svn as soon as we > > release wxruby2 alpha1. > > - keep a close eye on how commits process etc are working, and try out > > bzr on top of svn.Interesting comparison of distributed vcs systems: http://changelog.complete.org/posts/528-Whose-Distributed-VCS-Is-The-Most-Distributed.html I know for sure that the stuff about bzr is inaccurate, so I will assume that the critiques of other systems are also questionable. However, he seems to say that SVN cannot do several things related to branching that I would have thought it could do. Can someone who has used SVN comment? Thanks, Kevin
On Tue, 2006-08-01 at 18:55 +0100, Alex Fenton wrote:> A little patch to add Wx::GenericDirCtrl. A non-native control (on OS X > at least) but maybe useful to someone. I have tested it but think it > should just be added to controls.rb sample - will do later when i have > fixed some other probs with that.Applied, thanks.> Also, I''ve started putting class-specifc style constants in the relevant > .i file, as discussed previosuly - will submit a patch doing this for > existing classes down the line.Great.> Lastly have added a page to the wiki showing class support by category - > looks a lot better for wxruby2 done this way, shows how much of the core > GUI api we support now. > > http://wxruby.rubyforge.org/wiki/wiki.pl?ClassesSupportedByCategoryVery nice! Kevin