I''m a bit new to working on a rubyforge/sourceforge/open source project, so excuse my obliviousness. What is the preferred way of submitting a patch to wxruby? Thanks, Nick
Nick wrote:> I''m a bit new to working on a rubyforge/sourceforge/open source project, > so excuse my obliviousness. What is the preferred way of submitting a > patch to wxruby?I am completely new to full-on distributed development, so excuse my obliviousness but I have absolutely no idea. A couple weeks ago, I started exploring non-CVS version control systems that make it easy for multiple people to work on a project, without everyone committing directly to the official tree. Examples are arch, darcs, and monotone. Unfortunately, so far, none of these that meet all the needs of wxRuby. In case you are interested, the leading contender seems to be monotone: http://www.venge.net/monotone/ It isn''t fully ported to Cygwin yet, let alone native Win32. And it doesn''t yet have all the simple commands that a typical developer would want (like diff a single file against the repository head revision). Otherwise, it seems pretty good. So, for now, I guess I''ll have to learn how to use existing diff/patch tool set, because aside from performing simple diffs on files, I have never used them. Can anyone point me to the best set of tools, and the best tutorial? I really appreciate people sending in patches, so I''ll try to figure out how to apply them by this weekend. Worst-case, I''ll do manual patching. Thanks, Kevin
Kevin Smith (wxRuby@qualitycode.com) wrote:> A couple weeks ago, I started exploring non-CVS version control systems > that make it easy for multiple people to work on a project, without > everyone committing directly to the official tree. Examples are arch, > darcs, and monotone.Incidentally I also become interested in suh tools recently :-)> It isn''t fully ported to Cygwin yet, let alone native Win32. And it > doesn''t yet have all the simple commands that a typical developer would > want (like diff a single file against the repository head revision). > Otherwise, it seems pretty good. > > So, for now, I guess I''ll have to learn how to use existing diff/patch > tool set, because aside from performing simple diffs on files, I have > never used them. Can anyone point me to the best set of tools, and the > best tutorial?Somehow, darcs evoked the most attention from my side (although not so much time yet, being over-occupied with other things :-( Being written in Haskell, I saw in mailing list archive about Win32, support, and ChangeLog file explicitly states this (as 0.9.13). Moreover, the author (David) seems responsive to the feedback. (last version even has some GUI support - wxhaskell :-) I can try to build it under MinGW and see what''s happenning. Maybe you can take a closer look. Sincerely, Gour -- Gour gour@mail.inet.hr Registered Linux User #278493
On 2003 Nov 13, at 11:33 AM, Gour wrote:> Somehow, darcs evoked the most attention from my sideWould that be the darcs side? <ducks> ;-) -- John Platte Principal Consultant, NIKA Consulting http://nikaconsulting.com/
Gour wrote:> Somehow, darcs evoked the most attention from my side (although not so much > time yet, being over-occupied with other things :-(I also looked at darcs, and like many things about it.> Being written in Haskell, I saw in mailing list archive about Win32, support, > and ChangeLog file explicitly states this (as 0.9.13).The fact that it is written in haskell is the biggest problem, in my opinion. First, because if I want to add a feature or fix a bug, I can''t. Secondly, because it is such an obscure language that it will never be able to have a large community of contributors. From a feature standpoint, monotone seems similar to darcs. And the monotone author seems about as responsive. But monotone is written in C++, which I am comfortable with. Before I would be willing to use darcs, I think it would either have to be far more mature than it is now, or it would have to be ported to a more popular language, like ruby, python, or C++. Kevin
Kevin Smith wrote:> > Gour wrote: > > Somehow, darcs evoked the most attention from my side (although > not so much > > time yet, being over-occupied with other things :-( > > I also looked at darcs, and like many things about it. > > > Being written in Haskell, I saw in mailing list archive about > Win32, support, > > and ChangeLog file explicitly states this (as 0.9.13). > > The fact that it is written in haskell is the biggest problem, in my > opinion. First, because if I want to add a feature or fix a bug, I > can''t. Secondly, because it is such an obscure language that it will > never be able to have a large community of contributors. > > From a feature standpoint, monotone seems similar to darcs. And the > monotone author seems about as responsive. But monotone is written in > C++, which I am comfortable with. > > Before I would be willing to use darcs, I think it would either have to > be far more mature than it is now, or it would have to be ported to a > more popular language, like ruby, python, or C++.What about Subversion? Curt
Curt Hibbs wrote:> What about Subversion?Thanks for asking :-) From what I can tell, subversion is "merely" an improved copy of CVS. It fixes the pesky things like having the history follow a file when it moves, and atomic commits. But it still uses a centralized repository, so it doesn''t seem to do enough to improve the branch/patch situation with multiple contributors to a project. Systems like arch, darcs, and monotone are much more radical, and powerful. Each contributor can publish their own tree on any web server (or in some cases an ftp or other kind of server), and the project maintainer can easily pull those patches directly into their own repository, and merge them (or discard them) all within the RCS system. Unfortunately, none of them are quite ready for wxRuby use today. Each one has at least one killer flaw, at least in my opinion. The flaws in arch (cross-platform issues) seem least likely to be solved[1]. I mentioned my concerns about darcs in my previous message. My current favorite is monotone, because it seems to have a good core, and merely lacks features. Rather than jump to subversion now for minimal benefits, I think I would rather wait for one of these to be ready, or for subversion to solve the distributed development puzzle in its own way. I am optimistic that monotone could be usable within a few months, if all goes well. Of course this all just my opinion, so forgive my ranting. For now, I''ll try to live with CVS and "normal" patch submissions. If that isn''t working, we''ll consider alternatives. Eventually, we''ll probably move away from CVS, at least as our primary system. Kevin [1] The author seems to see no value in arch running under MS Windows, and not much in Cygwin either.
Kevin Smith wrote:> > Curt Hibbs wrote: > > What about Subversion? > > Thanks for asking :-) > > From what I can tell, subversion is "merely" an improved copy of CVS. > It fixes the pesky things like having the history follow a file when it > moves, and atomic commits. > > But it still uses a centralized repository, so it doesn''t seem to do > enough to improve the branch/patch situation with multiple contributors > to a project. > > Systems like arch, darcs, and monotone are much more radical, and > powerful. Each contributor can publish their own tree on any web server > (or in some cases an ftp or other kind of server), and the project > maintainer can easily pull those patches directly into their own > repository, and merge them (or discard them) all within the RCS system.I have a personal interest in revision control systems, so sharing anything you find or opinions you have would be greatly appreciated.> Unfortunately, none of them are quite ready for wxRuby use today. Each > one has at least one killer flaw, at least in my opinion. The flaws in > arch (cross-platform issues) seem least likely to be solved[1]. I > mentioned my concerns about darcs in my previous message. My current > favorite is monotone, because it seems to have a good core, and merely > lacks features. > > Rather than jump to subversion now for minimal benefits, I think I would > rather wait for one of these to be ready, or for subversion to solve the > distributed development puzzle in its own way. I am optimistic that > monotone could be usable within a few months, if all goes well.Actually, I think that (for the foreseeable future) we are better served sticking with a central repository, CVS, and RubyForge. CVS is a defacto standard within the open source community and accessible to all. But personally this is a different story. For the last month or so I have been planning to install Subversion locally on my home network to serve as a backup system and historical archive for all of my work -- I just haven''t had time to actually do it yet. If you think there are viable alternatives for this purpose, I would love to hear your opinion. Curt
On Friday, Nov 14, 2003, at 07:22 Europe/Helsinki, Kevin Smith wrote:> Curt Hibbs wrote: >> What about Subversion?> From what I can tell, subversion is "merely" an improved copy of CVS.That hardly does it justice, sorry. We''ve been using subversion in our project (pdis.hiit.fi) for half a year now, and I''d have too say more good things than that. Sure it fixes quirks and is well designed, has WebDav and what not, but from my perspective the important things it brings are: 1 moves of directories. 2 unified model of branching and tagging off course then are the minor ones like 3 atomic commits over as big a change as you have (cvs can happily crash in the middle and you''re on your own) 4 much improved re-merging support 5 complete (with history) import from cvs To detail a little: 1 lets you start a project and reorganise the directory structure while going along, without losing history. That''s just short of revolutionary when coming from cvs. (Off course the pro will say you always could do that by going into the cvs admin area, but those days are luckily gone with subversion, which stores everything in a db) 2 really, subversion doesn''t know either tag or branch. It only knows a copy (with history). So both tags and branches are implemented as copy. In practise that means that you can do a tag, but then later start working on that tag and it becomes a branch (in cvs you ended up always putting a branch and a tag, just in case you might later want to work on a tag). As subversion implements copy-on-write, tags/branches are very cheap, as all it creates are basically pointers. But ... of course there is a but, but subversion is still a moving target http://subversion.tigris.org/project_status.html . Very rarely the schema or protocol changes and require reload or client/server version compatibility. And off course it''s not widely adopted. Specifically, rubyforge doesn''t have it, and I asked and they don''t want it (at least now). But if anyone is looking for a source control system for private use, I can only recommend it. Here is a list of others who use it http://subversion.tigris.org/svn-repositories.html. Torsten
Torsten Rueger wrote:> On Friday, Nov 14, 2003, at 07:22 Europe/Helsinki, Kevin Smith wrote: >> From what I can tell, subversion is "merely" an improved copy of CVS. > > That hardly does it justice, sorry. We''ve been using subversion in our > project (pdis.hiit.fi) for half a year now, and I''d have too say more > good things than that.Excellent. I was hoping to hear from a pro-subversion person. Honestly, I have not explored svn deeply because of its centralized repository design.> Sure it fixes quirks and is well designed, has WebDav and what not, but > from my perspective the important things it brings are: > 1 moves of directories.For me, this is quite nice, but not a huge feature. I rarely look back at histories anyway.> 2 unified model of branching and taggingThis is one that I need to learn more about. The only branching I have done in CVS is through eclipse. In that environment, I can make a tag, and a month later I can go back and check out that tag, and treat it like a branch. I assumed that was part of CVS, but perhaps eclipse is doing some magic on top.> 3 atomic commits over as big a change as you have (cvs can happily crash > in the middle and you''re on your own)Of course this is an improvement, but on a small project with reliable connections it doesn''t seem critical.> 4 much improved re-merging supportThis is a big one. Can you point me to any web links that describe how two repositories can stay in sync with each other? Responding more to Curt: The reason I want to get away from centralized repositories is because contributors should be able to have full version control capabilities without affecting the "official" repository. Contributions from people new to the project should only be checked in to the main repository after they have been approved by the maintainer. Granting write rights in a CVS repository is a big deal, and not to be done lightly. Of course, each person can have their own local CVS repository (or whatever system they prefer), and we can trade diff/patch files. But that puts a burden on the maintainer to merge each patch, and each contributor has to re-merge the official tree changes back into their personal tree (frequently). The whole process becomes quite error-prone, because it is easier to do the wrong thing (getting out of sync) than the right thing. At least, that''s the way I understand it today. I hope I''m wrong, but I''m pretty sure this is why Linus uses BitKeeper, and why the arch folks are so passionate about that project.> 5 complete (with history) import from cvsYes, this is valuable, although for a young project like wxRuby I could live without it. Many systems do this, including arch and monotone. Thanks for your comments! Kevin
Kevin Smith (wxRuby@qualitycode.com) wrote:> The fact that it is written in haskell is the biggest problem, in my > opinion. First, because if I want to add a feature or fix a bug, I > can''t. Secondly, because it is such an obscure language that it will > never be able to have a large community of contributors.Well, I''m using on a daily basis many open-source programs and do not expect (in foreseeable future) to contribute to each one. If they do the job, then it''s fine.> From a feature standpoint, monotone seems similar to darcs. And the > monotone author seems about as responsive. But monotone is written in > C++, which I am comfortable with.One of the reasons I''m staying away from Subversion is that I was warned about database corruption with it, and, afaik, monotone also uses some kind of embedded database, whic left me with the arch & darcs :-)> > Before I would be willing to use darcs, I think it would either have to > be far more mature than it is now, or it would have to be ported to a > more popular language, like ruby, python, or C++.Since darcs is based on its underlying ''patch theory'' which is probably much easier expressible in FP language like Haskell, than in ''imperative'' languages, I''m seriously doubt it will be re-written (at least from author''s side). What are the features you are missing in darcs? Today I was able to compile and run darcs under MinGW, but there are still some gotchas for resolve. imho, for a ''light'' project like wxruby, it will be nice to have some distributed VCS (darcs has simple ability to push & pull to/from repository), but I''m sure you''ll choose the most convenient one. Sincerely, Gour -- Gour gour@mail.inet.hr Registered Linux User #278493
Gour wrote:> One of the reasons I''m staying away from Subversion is that I was warned about > database corruption with it, and, afaik, monotone also uses some kind of > embedded database, whic left me with the arch & darcs :-)Good point. Yes, monotone uses a sqlite database. You have almost convinced me to rewrite darcs in Ruby :-)> What are the features you are missing in darcs?Well, one of my concerns is mentioned in the darcs manual introduction: "Darcs is not intended to maintain a history of versions, although it is possible to kludge together such a revision history, either by making each new patch depend on all previous patches, or by tagging regularly." Perhaps because I''ve been immersed in VSS and CVS so long, it seems like being able to look back at a history of revisions is an important feature. I might be wrong, though. Perhaps in a distributed development environment, it isn''t helpful or relevant. A simpler example is that darcs doesn''t yet have the ability to do a single-file "diff". You can only diff an entire tree. To be fair, monotone is also missing a single-file diff command, and currently can only list history of trees, not individual files. But I have confidence that a C++ programmer will be available and motivated to write the missing code. As an unfair jab, some of the darcs commands sound confusing, although they probably make sense when you are familiar with the system: remove, rollback, unrecord, unpull, revert, unrevert. But seriously, I''m not against darcs. I sincerely hope it becomes a successful project. If it already had the features I need, I would probably start using it. I think the patchset theory is probably a really good thing, and I like the directory structure. The whole project has a nice feel to it. Except for that haskell thing :-) Kevin
Kevin Smith wrote:> > Gour wrote: > > One of the reasons I''m staying away from Subversion is that I > was warned about > > database corruption with it, and, afaik, monotone also uses > some kind of > > embedded database, whic left me with the arch & darcs :-) > > Good point. Yes, monotone uses a sqlite database. You have almost > convinced me to rewrite darcs in Ruby :-)That was a problem with an older version of subversion that has since been fixed.> > What are the features you are missing in darcs? > > Well, one of my concerns is mentioned in the darcs manual introduction: > "Darcs is not intended to maintain a history of versions, although it is > possible to kludge together such a revision history, either by making > each new patch depend on all previous patches, or by tagging regularly." > > Perhaps because I''ve been immersed in VSS and CVS so long, it seems like > being able to look back at a history of revisions is an important > feature. I might be wrong, though. Perhaps in a distributed development > environment, it isn''t helpful or relevant.Yikes! That would be like living without backups. 99% of the time you don''t need them, but the 1% that you do, you are really glad its there. The revision history is precisely the reason I''m planning to install Subversion on my home network for personal use in all my projects. Curt
Kevin Smith (wxRuby@qualitycode.com) wrote:> Good point. Yes, monotone uses a sqlite database. You have almost > convinced me to rewrite darcs in Ruby :-)Why not learn Haskell? Today there is a post on darcs'' ml by well-known Rubyist submitting a patch :-)> > >What are the features you are missing in darcs? > > Well, one of my concerns is mentioned in the darcs manual introduction: > "Darcs is not intended to maintain a history of versions, although it is > possible to kludge together such a revision history, either by making > each new patch depend on all previous patches, or by tagging regularly." > > Perhaps because I''ve been immersed in VSS and CVS so long, it seems like > being able to look back at a history of revisions is an important > feature. I might be wrong, though. Perhaps in a distributed development > environment, it isn''t helpful or relevant.I suggest you to post to the author and you''ll get his response regards. imho, darcs operates differently than CVS-like systems and therefore some sort of paradigm shitf is necessary.> A simpler example is that darcs doesn''t yet have the ability to do a > single-file "diff". You can only diff an entire tree. > > To be fair, monotone is also missing a single-file diff command, and > currently can only list history of trees, not individual files. But I > have confidence that a C++ programmer will be available and motivated to > write the missing code. >If I recall correctly, there was soem discussion on the list recently. Pls. check it.> As an unfair jab, some of the darcs commands sound confusing, although > they probably make sense when you are familiar with the system: remove, > rollback, unrecord, unpull, revert, unrevert.Well I didn''t fell to deep into CVS well, so I''m OK with them :-)> > But seriously, I''m not against darcs. I sincerely hope it becomes a > successful project. If it already had the features I need, I would > probably start using it. I think the patchset theory is probably a > really good thing, and I like the directory structure. The whole project > has a nice feel to it. Except for that haskell thing :-)I was looking long time on subversion, but I have a feeling that it is getting too bloated, while darcs is plug & play, and it can (could) work under Win platform. Interestingly enough there is discusssion archived in mailing list where David is comparing his theory model with subversion''s - pretty similar, and explains the differences. Take a look. otoh, tl''s argument against darcs is that he doesn''t like the theory :-) Sincerely, Gour -- Gour gour@mail.inet.hr Registered Linux User #278493
It''s refreshing to know that everyone has their own personal favorite revision control system. Personally, as long as we don''t have to use ''SourceSafe'', I''ll be ok. I do have some patches I''d like to submit in the next couple of days, or at least before I think we can settle the argument of ''which revision control system is better''. What is the best way for me to submit them? Nick Kevin Smith wrote:> Gour wrote: > >> One of the reasons I''m staying away from Subversion is that I was >> warned about >> database corruption with it, and, afaik, monotone also uses some kind >> of embedded database, whic left me with the arch & darcs :-) > > > Good point. Yes, monotone uses a sqlite database. You have almost > convinced me to rewrite darcs in Ruby :-) > >> What are the features you are missing in darcs? > > > Well, one of my concerns is mentioned in the darcs manual > introduction: "Darcs is not intended to maintain a history of > versions, although it is possible to kludge together such a revision > history, either by making each new patch depend on all previous > patches, or by tagging regularly." > > Perhaps because I''ve been immersed in VSS and CVS so long, it seems > like being able to look back at a history of revisions is an important > feature. I might be wrong, though. Perhaps in a distributed > development environment, it isn''t helpful or relevant. > > A simpler example is that darcs doesn''t yet have the ability to do a > single-file "diff". You can only diff an entire tree. > > To be fair, monotone is also missing a single-file diff command, and > currently can only list history of trees, not individual files. But I > have confidence that a C++ programmer will be available and motivated > to write the missing code. > > As an unfair jab, some of the darcs commands sound confusing, although > they probably make sense when you are familiar with the system: > remove, rollback, unrecord, unpull, revert, unrevert. > > But seriously, I''m not against darcs. I sincerely hope it becomes a > successful project. If it already had the features I need, I would > probably start using it. I think the patchset theory is probably a > really good thing, and I like the directory structure. The whole > project has a nice feel to it. Except for that haskell thing :-) > > Kevin > > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > >
Nick wrote:> It''s refreshing to know that everyone has their own personal favorite > revision control system.LOL! It seems to be a lot like choosing an editor. The all work, but each uses a different model, and once you''ve gotten used to one it''s hard to switch.> I do have some patches I''d like to submit in > the next couple of days, or at least before I think we can settle the > argument of ''which revision control system is better''. What is the best > way for me to submit them?I''m going to try doing a diff/patch today, and I''m 90% sure that''s going to be the best method. After my attempt works (or fails), I''ll let everyone know. I don''t envision switching wxruby away from CVS for at least a couple months, and that is probably optimistic. Thanks, Kevin
On Friday, Nov 14, 2003, at 18:59 Europe/Helsinki, Kevin Smith wrote:> For me, this is quite nice, but not a huge feature. I rarely look back > at histories anyway.In my experience that starts when there are releases out there and one tries to track down a change one hasn''t made oneself.>> 3 atomic commits over as big a change as you have (cvs can happily >> crash in the middle and you''re on your own) > > Of course this is an improvement, but on a small project with reliable > connections it doesn''t seem critical.There is the other thing that one can then undo just that commit, or (months later) even just know which changes (of several files) belong together.>> 4 much improved re-merging support > > This is a big one. Can you point me to any web links that describe how > two repositories can stay in sync with each other?That as such, I don''t know. Subversion is a central repository, I don''t know if it has support for multiple repositories. What I meant was keeping different branches of the same repository in sync. The two applications of that that i know are - creating (and delivering) a versions, later making changes on that branch (due to bug reports) and merging those changes into the main branch - vendor branching or 3rd party library maintenance, where you import somebody''s library into your repository, make changes to it (only because you have to) and later upgrade the library and you want to re apply your changes. Both of these are nicely covered in chapter 4 of the subversion book: http://svnbook.red-bean.com/html-chunk/ch04.html . Concretely, subversion has the "switch" command, which switches a path in your working repository against another version of it. (Applying you local changes to the other version while doing so).> Responding more to Curt: The reason I want to get away from > centralized repositories is because contributors should be able to > have full version control capabilities without affecting the > "official" repository. Contributions from people new to the project > should only be checked in to the main repository after they have been > approved by the maintainer. Granting write rights in a CVS repository > is a big deal, and not to be done lightly.So for this, the way one could use svn is to assign a writeable area (directory) of the repository to each contributor. You''d start that area by copying (with history) the whole project. They make their changes and transfer them to a fresh copy (in their tree) before they want it committed.> Of course, each person can have their own local CVS repository (or > whatever system they prefer), and we can trade diff/patch files. But > that puts a burden on the maintainer to merge each patch, and each > contributor has to re-merge the official tree changes back into their > personal tree (frequently). The whole process becomes quite > error-prone, because it is easier to do the wrong thing (getting out > of sync) than the right thing.Then people would just send mail to the maintainer, he/she would "switch" their changes into his/her repository, check them out and possibly commit. (BTW: in all this remember svn has copy on write, so creating a copy is really cheap) Or so the theory. I haven''t done this. Our project is also small and young. Once you read the book, you''ll know as much as me. Good luck, I''d say it''s an interesting read for any developer, Torsten