wxruby users - Aug 2005 - Some patches.

Hi,

in my path of getting the controls sample to work nicely, I fixed some
classes on the way, see the attached diffs. I had some difficulties, but
could track down all stupid bugs and am now almost happy with the code
:)

(I had the complete ImageHandler hieracy implemented at some time, but
than I discovered the error was not in unloaded ImageHandlers but in the
controls-program which does not load the images correctly. *arrrg*)

OK, this are the patches:

wxruby-crlf.patch - There is some lineending cruft in some sorce files.
While this is not critical, it is annoying, so I removed them.

typemap-fix.patch - One paranthesis too much - seems this typemap is not
in use or the compiler would have complained...

togglebutton-fix.patch - Make the ToggleButton class compile on all
platforms - Should not be problemtical, but I could only test on Linux
(wxGTK), the wx manual says: "NB: This class is not available under
wxUniversal ports such as wxX11." - I don''t think this is a
problem,
since our main targets are wxMSW, wxMAC and wxGTK, right?

spinevt-fix.patch - Swap the SPIN_UP and SPIN_DOWN events, the were
reversed.

spinctrl-fix.patch - Remove some workaround code - this works without
problems in wxGTK, I tested the set_selection function and it does like
it is told ;)

notebook-fix.patch - Notebook works in wxGTK, so no need to disable it.

remove-kluges.patch - Remove Ruby workarounds for Notebook and
ToggleButton, they are not needed with my other patches.

choice-fix.patch - Don''t disable the useful constructor for wxChoice.

rake-shell.patch - This construct does not work on my system. I thought
the backticks already start a shell? Anyway, since wx-config has no
absolute path, the shell can not find it.

fix-controls-sample.patch & icons.tar.gz - Some small changes, so the
controls-sample runs in all its glory. :) The icons are needed or the
sample crashes with a nasty GTK error (on my Linux system). To run
without the icons you have to remove the last parameter of each call to
@m_notebook.add_page.

I''m thinking about adding more code from the C++ controls sample and
make the code a little bit more rubyish, so stay tuned :)

Greetings Tobi

PS: I hate working with CVS. Anyone interested moving to something
better? I would prefer something like Darcs or Arch.

-- 
GPG-Key 0xE2BEA341 - signed/encrypted mail preferred
My, oh so small, homepage: http://portfolio16.de/
http://www.fli4l.de/ - ISDN- & DSL-Router on one disk!
Registered FLI4L-User #00000003













_______________________________________________
wxruby-users mailing list
wxruby-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/wxruby-users

Tobias Gruetzmacher wrote:
> OK, this are the patches:
Thanks! I''ll reply to the patches themselves in other emails.
> PS: I hate working with CVS. Anyone interested moving to something
> better? I would prefer something like Darcs or Arch.
I hate CVS too, as I have mentioned several times on the list. This 
remains a "hot button" topic for me, so this is probably a more
detailed
response than you were expecting.

A year or so ago, I started to shift the wxruby archives to darcs, but 
only one other contributor was using it. Eventually it became clear that 
the project would be better off staying with CVS. Perhaps things have 
changed now. My guess is that a year from now, wxruby *will* be using a 
distributed SCM tool.

First off, I just don''t see subversion as a worthwhile option for us. 
Although it is better than CVS (which it its goal), it is still 
centralized. So it is incrementally better, but does not solve some of 
the big problems, so I don''t think it''s worth the pain of
switching.

There are several distributed SCM tools, but only a couple would 
actually be candidates for use on the wxruby project. First, let''s
agree
on some criteria. I can''t imagine wxruby adopting an SCM tool without 
these features:

0. Must be distributed, and be Free Software
    This eliminates perforce, subversion, and some others.

1. Must have clients available for Linux, MS Windows, and Mac OS X
    This eliminates ArX, Bazaar (baz), GIT/cogito, GNU arch (tla), and
    monotone.

2. Must be "production quality" with reasonable feature set
    This eliminates FastCST (and some others).

We are left with:
- Bazaar-NG (bzr)
- Codeville
- darcs
- Mercurial (?)
- svk

Of those, Codeville and svk require a cgi app on the server, which I 
dislike. On the other hand, Bazaar-NG, darcs, and Mercurial store their 
repos *inside* the working directory, which I also dislike. So none of 
these are ideal for me, but I would be willing to try any of them.

Darcs is definitely the most mature, so I suppose it would be the 
default choice if nobody has strong reasons to prefer one of the others. 
For a small project like wxruby, darcs would probably work fine.

So, I''ve said it before and I''ll say it again: If it will make
it easier
for people to contribute code to wxruby, I would happily try out one of 
these systems. It would take at least a couple of you saying "Yes! Do 
it!", and also no strong/valid objections from other folks.

We would also have to decide whether to set up a one-way or 
bidirectional CVS gateway, for backward compatibility. I don''t have
time
to set that up and maintain it, so someone would have to volunteer to 
take that on, or else we would have to decide that it''s not necessary.

Thoughts?

Kevin

Hi Kevin,

+1 for darcs.
The fact that it stores the repo inside the wd I actually find and
advantage  and contributes to the simplicty of darcs.
Jani

I have only used cvs and svn in the past and looked at the darcs site
for 5 minutes and it looks pretty straight forward, looks like it is
easy to install on every platform. If we are not going with a central
repository then I vote for darcs.

We will have to have some kind of quick howto somewhere showing the
basics since it is not a widely used revision control system.

Sean

On 8/9/05, Jani Monoses <jani.monoses@gmail.com>
wrote:
> Hi Kevin,
> 
> +1 for darcs.
> The fact that it stores the repo inside the wd I actually find and
> advantage  and contributes to the simplicty of darcs.
> Jani
> 
> _______________________________________________
> wxruby-users mailing list
> wxruby-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>

Tobias Gruetzmacher wrote:
> 
> OK, this are the patches:
They are all committed. Very nice work!

In the future, if possible, please generate patches that will apply with 
-p1 instead of -p0. I don''t know why -p1 is the standard, but some
patch
manipulation tools won''t work with -p0 patches.

Thanks,

Kevin

We have two votes for darcs, zero votes for other SCM systems, and zero 
votes to stay with CVS.

There are some nice tools for doing a one-time conversion from CVS to 
darcs, so it won''t be a problem with us losing history. There are also 
some processes for maintaining a two-way CVS-darcs gateway, but they 
don''t seem to be automated and tested.

So to keep things simple, My preference would be to *only* keep a darcs 
repository updated, and to kill off the wxruby2 CVS repository on 
rubyforge. Regular snapshot tarballs would be available for any wxruby2 
developers who don''t want to use darcs for some reason.

If someone were sufficiently motivated, they should be able to set up a 
one-way gateway from the "official" darcs wxruby2 repo back into a CVS
repo, although I would resist hosting it at rubyforge, since it
wouldn''t
have "official" status.

Does all of that sound reasonable? Is this something we should do before 
the first wxruby2 preview release? Or between the preview and the real 
release? Or after the real release?

Kevin

Hi,

On Sun, Aug 14, 2005 at 12:48:30AM -0400, Kevin Smith
wrote:
> So to keep things simple, My preference would be to *only* keep a darcs 
> repository updated, and to kill off the wxruby2 CVS repository on 
> rubyforge. Regular snapshot tarballs would be available for any wxruby2 
> developers who don''t want to use darcs for some reason.
Sounds good.
> Does all of that sound reasonable? Is this something we should do before 
> the first wxruby2 preview release? Or between the preview and the real 
> release? Or after the real release?
I think it would be good to do it as soon as possible. Just my $0.02.

BTW: I''m currently refactoring the controls.rb sample more. Expect some
more patches soon :)

Greetings Tobi

-- 
GPG-Key 0xE2BEA341 - signed/encrypted mail preferred
My, oh so small, homepage: http://portfolio16.de/
http://www.fli4l.de/ - ISDN- & DSL-Router on one disk!
Registered FLI4L-User #00000003
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://rubyforge.org/pipermail/wxruby-users/attachments/20050814/70a40a5e/attachment.bin

Tobias Gruetzmacher wrote:
> 
> I think it would be good to do it as soon as possible. Just my $0.02.
Noted. Awaiting input from other folks.

Meanwhile, I have started playing with darcs (again), and have published 
a darcs repo of my SpaceMonkeys game, which is the largest wxruby app I 
have written (years ago). I had to tweak it bit to get it working with 
the very latest wxruby2 head (as of two minutes ago). The main 
SpaceMonkeys screen comes up, but if you try to do a couple actions it 
generally crashes. Most likely wxruby2 memory management errors.

Anyway, if you would like to experiment with darcs, try getting 
SpaceMonkeys with this command:

   darcs get http://fxa.org/darcs/SpaceMonkeys/main/

This will create a main/ directory under your current directory, and 
will populate it with the latest official SpaceMonkeys head.

At any time, you can pull my latest SpaceMonkeys changes into your tree 
by changing into your "SpaceMonkeys/main" directory and doing:

   darcs pull http://fxa.org/darcs/SpaceMonkeys/main/

It will be critical to use standard procedures with darcs, including 
using standard names and locations for branches. I''m going to read more
about darcs "best practices", but at the moment I am reserving the 
"main" branch name for the latest official development tree. That name
may change based on what I read. Whatever naming convention I decide on, 
it will be used for both SpaceMonkeys and wxruby2.

As I develop those conventions, I''ll email them to the wxruby list. 
We''ll probably also need some wxruby wiki pages for darcs-related
stuff.

Kevin

Holy cow!  Darcs worked, just like that.  I ave spacemonkeys on my 
computer now.  But it won''t bring up the main window on Windows. 
I''ll
investigate the errors and letcha know if there''s a patch needed.

Roy

Kevin Smith wrote:
> Tobias Gruetzmacher wrote:
>
>>
>> I think it would be good to do it as soon as possible. Just my $0.02.
>
>
> Noted. Awaiting input from other folks.
>
> Meanwhile, I have started playing with darcs (again), and have 
> published a darcs repo of my SpaceMonkeys game, which is the largest 
> wxruby app I have written (years ago). I had to tweak it bit to get it 
> working with the very latest wxruby2 head (as of two minutes ago). The 
> main SpaceMonkeys screen comes up, but if you try to do a couple 
> actions it generally crashes. Most likely wxruby2 memory management 
> errors.
>
> Anyway, if you would like to experiment with darcs, try getting 
> SpaceMonkeys with this command:
>
>   darcs get http://fxa.org/darcs/SpaceMonkeys/main/
>
> This will create a main/ directory under your current directory, and 
> will populate it with the latest official SpaceMonkeys head.
>
> At any time, you can pull my latest SpaceMonkeys changes into your 
> tree by changing into your "SpaceMonkeys/main" directory and
doing:
>
>   darcs pull http://fxa.org/darcs/SpaceMonkeys/main/
>
> It will be critical to use standard procedures with darcs, including 
> using standard names and locations for branches. I''m going to read
> more about darcs "best practices", but at the moment I am
reserving
> the "main" branch name for the latest official development tree.
That
> name may change based on what I read. Whatever naming convention I 
> decide on, it will be used for both SpaceMonkeys and wxruby2.
>
> As I develop those conventions, I''ll email them to the wxruby
list.
> We''ll probably also need some wxruby wiki pages for darcs-related
stuff.
>
> Kevin
> _______________________________________________
> wxruby-users mailing list
> wxruby-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>
>
>

> Does all of that sound reasonable? Is this something we should do before
> the first wxruby2 preview release? Or between the preview and the real
> release? Or after the real release?
I think it should be done before the preview release, that way we have
it all worked out before the big 1.0 release (or whatever it will be
called).

Sean

Kevin Smith wrote:
> We are left with:
> - Bazaar-NG (bzr)
> - Codeville
> - darcs
> - Mercurial (?)
> - svk
> 
> Of those, Codeville and svk require a cgi app on the server, which I 
> dislike. On the other hand, Bazaar-NG, darcs, and Mercurial store their 
> repos *inside* the working directory, which I also dislike. So none of 
> these are ideal for me, but I would be willing to try any of them.
> 
> Darcs is definitely the most mature, so I suppose it would be the 
> default choice if nobody has strong reasons to prefer one of the others. 
> For a small project like wxruby, darcs would probably work fine.
I''m having second thoughts about darcs. The repo-inside-working-tree 
model is really bad for MS Windows users. Distributed SCM tools really 
rely on branches being cheap, and if you don''t have "hard
links" (which
is true with most Windows boxes), then you either have to work 
differently (inefficiently) or suffer with slowness and excessive disk 
usage.

So I really believe that darcs would work for a while, but also that we 
would end up switching to a different tool later. I''m concerned that 
switching twice (once from CVS to darcs, and then from darcs to 
something else) would be too confusing and painful.

In the time that has passed since I wrote the message quoted above, bzr 
has improved in a couple ways. First, the Ubuntu Linux folks (Canonical) 
are officially planning to adopt it as their one and only version 
control tool later this year (October). Second, they have said that 
solving the repo-within-working-tree problem for non-hardlink systems is 
a high priority feature.

Thus, I think I want to switch directly from CVS to bzr. However, I 
don''t think bzr is quite ready, since they are about to make a change
to
their repository disk format. Also, they claim bzr works under MS 
Windows, but they don''t seem to have docs describing how to install it.
Therefore, I think I want to wait a while longer before switching from CVS.

Meanwhile, I have set up a public bzr repository of my SpaceMonkeys 
game, as a test. You can install bzr and grab a copy with this command:

    bzr branch http://fxa.org/bzr/SpaceMonkeys/official

This will create a directory named "official" and will pull a copy of 
the official sources into it. As with the darcs test, I would appreciate 
hearing your results if you try this. Especially if you try it with MS 
Windows (without cygwin). Here''s the bzr site:

   http://www.bazaar-ng.org/

Kevin

The first problem I see is that is requires Python 2.4 and on Mac OS X
10.4 python 2.3.5 is installed by default. Just one extra hurdle for
developers looking to contribute to the project, if we have too many
install requirements (Ruby 1.8, SWIG, Python 2.4, bzr) some may decide
not to contribute.

At least with darcs binaries can be downloaded.

Just my thoughts

Sean

On 8/28/05, Kevin Smith <wxruby@qualitycode.com>
wrote:
> Kevin Smith wrote:
> > We are left with:
> > - Bazaar-NG (bzr)
> > - Codeville
> > - darcs
> > - Mercurial (?)
> > - svk
> >
> > Of those, Codeville and svk require a cgi app on the server, which I
> > dislike. On the other hand, Bazaar-NG, darcs, and Mercurial store
their
> > repos *inside* the working directory, which I also dislike. So none of
> > these are ideal for me, but I would be willing to try any of them.
> >
> > Darcs is definitely the most mature, so I suppose it would be the
> > default choice if nobody has strong reasons to prefer one of the
others.
> > For a small project like wxruby, darcs would probably work fine.
> 
> I''m having second thoughts about darcs. The
repo-inside-working-tree
> model is really bad for MS Windows users. Distributed SCM tools really
> rely on branches being cheap, and if you don''t have "hard
links" (which
> is true with most Windows boxes), then you either have to work
> differently (inefficiently) or suffer with slowness and excessive disk
> usage.
> 
> So I really believe that darcs would work for a while, but also that we
> would end up switching to a different tool later. I''m concerned
that
> switching twice (once from CVS to darcs, and then from darcs to
> something else) would be too confusing and painful.
> 
> In the time that has passed since I wrote the message quoted above, bzr
> has improved in a couple ways. First, the Ubuntu Linux folks (Canonical)
> are officially planning to adopt it as their one and only version
> control tool later this year (October). Second, they have said that
> solving the repo-within-working-tree problem for non-hardlink systems is
> a high priority feature.
> 
> Thus, I think I want to switch directly from CVS to bzr. However, I
> don''t think bzr is quite ready, since they are about to make a
change to
> their repository disk format. Also, they claim bzr works under MS
> Windows, but they don''t seem to have docs describing how to
install it.
> Therefore, I think I want to wait a while longer before switching from CVS.
> 
> Meanwhile, I have set up a public bzr repository of my SpaceMonkeys
> game, as a test. You can install bzr and grab a copy with this command:
> 
>     bzr branch http://fxa.org/bzr/SpaceMonkeys/official
> 
> This will create a directory named "official" and will pull a
copy of
> the official sources into it. As with the darcs test, I would appreciate
> hearing your results if you try this. Especially if you try it with MS
> Windows (without cygwin). Here''s the bzr site:
> 
>    http://www.bazaar-ng.org/
> 
> Kevin
> _______________________________________________
> wxruby-users mailing list
> wxruby-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>

Hi Kevin,

does lack of hardlinks cause such inconveniences for a small project like 
wxruby?
I am happy with your chosing either darcs or bzr, but could you publish 
wxruby2 in one of them ;) ?
That would make possible contributors be more compelled to try out and test 
the distributed devel scenario
than with the game only

thanks
Jani
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/wxruby-users/attachments/20050829/3de11cb4/attachment.htm

Jani Monoses wrote:
> Hi Kevin,
> 
> does lack of hardlinks cause such inconveniences for a small project like 
> wxruby?
Yes, although to a much smaller degree than it would with a larger 
project. The longer the history and the more files there are in the 
project, the bigger the problem.
> I am happy with your chosing either darcs or bzr, but could you publish 
> wxruby2 in one of them ;) ?
> That would make possible contributors be more compelled to try out and test
> the distributed devel scenario
> than with the game only
I am reluctant to publish a darcs repo unless we really expect to use 
darcs. Same with bzr. I could easily publish a one-time snapshot repo in 
either of those, but keeping it updated would be quite a time burden for 
me right now. So it would be stale almost immediately, which seems worse 
than not having one at all.

Perhaps someone else could set up either a darcs or bzr mirror of the 
official CVS repo. That would allow contributors to pretend that the 
project had switched, and I would just have to figure out how to accept 
darcs/bzr patches and get them checked into CVS.

Kevin

Sean Long wrote:
> The first problem I see is that is requires Python 2.4 and on Mac OS X
> 10.4 python 2.3.5 is installed by default. Just one extra hurdle for
> developers looking to contribute to the project, if we have too many
> install requirements (Ruby 1.8, SWIG, Python 2.4, bzr) some may decide
> not to contribute.
> 
> At least with darcs binaries can be downloaded.
Hm. That is a consideration. Do you know how easy or difficult it is to 
install python 2.4 on Mac?

Kevin

> Hm. That is a consideration. Do you know how easy or difficult it is to
> install python 2.4 on Mac?
Well for me it would probably be easy since I have DarwinPorts (like
BSD ports) installed and can type:
sudo port install python24

the same could could probably be done with fink (like apt-get for Mac OS X)

I would then have to make sure the new install comes first in my PATH
or create a symbolic link to the new version.

So not really all that hard if you know what to do, just a hassle.

Sean

Hi,

On Mon, Aug 29, 2005 at 12:04:44AM -0400, Kevin Smith
wrote:
> I''m having second thoughts about darcs. The
repo-inside-working-tree
> model is really bad for MS Windows users. Distributed SCM tools really 
> rely on branches being cheap, and if you don''t have "hard
links" (which
> is true with most Windows boxes), then you either have to work 
> differently (inefficiently) or suffer with slowness and excessive disk 
> usage.
This only becomes a problem when a Windows user wants to create
branches, right? So he has to make a full copy of his repository.

I just looked at the numbers with wxruby2 in darcs (created with
cvs2darcs just yesterday):
Size of source: 5084 kB
Size of complete darcs repository: 23004 kB
Size of _darcs (without _darcs/current): 12832 kB

Now a way to optimize this in darcs is to create checkpoints and let the
contributers checkout only partial repositories. I put a checkpoint to
the tag "v0_0_28". This adds about 1300 kB to the repository. When I
checkout that partial repository (onto anothe filesystem) I get a new
repository:

Complete size: 11492 kB
Size of _darcs (without _darcs/current): 1364 kB

So the best way to optimize the space-usage for Windows-User would be to
add checkpoints whenever the repository grows over a certain size. Not
too much a burden if you ask me.

And people with space-problems probably would have a hard time compiling
wxruby2 anyway: 60980 kB are the object files and the lib on my Linux
box...

Some statistics over the scalability of darcs from one user:
http://article.gmane.org/gmane.comp.version-control.darcs.user/7082
> So I really believe that darcs would work for a while, but also that we 
> would end up switching to a different tool later. I''m concerned
that
> switching twice (once from CVS to darcs, and then from darcs to 
> something else) would be too confusing and painful.
I agree that different switches are really not nice for all people who
have to learn yet another tool... But I DO think that darcs scales well.

BTW: So I already have done the CVS-to-darcs-thing, I can also put it
online. I try to keep it current. The stuff is at
http://darcs.portfolio16.de/wxruby2/ - use "darcs get --partial" to
only
get the changes from the last tag till now.

Greetings Tobi

-- 
GPG-Key 0xE2BEA341 - signed/encrypted mail preferred
My, oh so small, homepage: http://portfolio16.de/
http://www.fli4l.de/ - ISDN- & DSL-Router on one disk!
Registered FLI4L-User #00000003
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://rubyforge.org/pipermail/wxruby-users/attachments/20050830/90e5012a/attachment.bin

Tobias Gruetzmacher wrote:
> On Mon, Aug 29, 2005 at 12:04:44AM -0400, Kevin Smith wrote:
> 
>>I''m having second thoughts about darcs. The
repo-inside-working-tree
>>model is really bad for MS Windows users. 
> 
> This only becomes a problem when a Windows user wants to create
> branches, right? So he has to make a full copy of his repository.
Right. Which in darcs is several times a day, if you are doing active 
development. Sometimes several times within minutes of each other. For 
example, today I probably would have wanted to create 10-20 branches 
within about 2 hours. Each would have lasted perhaps 15 minutes before I 
would have deleted it. Except one (in addition to the mainline) that I 
would still have.
> I just looked at the numbers with wxruby2 in darcs (created with
> cvs2darcs just yesterday):
> Size of source: 5084 kB
> Size of complete darcs repository: 23004 kB
> Size of _darcs (without _darcs/current): 12832 kB
Ok. Let''s say that wxruby2 is perhaps 10% of the size it will be a year
from now. So we are looking at a 230 meg branch (working tree + all of 
_darcs). Create a few branches, and that starts to get significant. Can 
a MS Windows user estimate how long it would take to copy a 230 meg 
directory containing perhaps a couple thousand files? Time is at least 
as important as disk space.

Then there is network bandwidth, and server disk space. If we''re 
encouraging people to host their own repos (which I want to do), then 
those become issues. I''m not even sure how to calculate bandwidth, but 
many hosting accounts are limited to tens or hundreds of megabytes. 
Hosting even five 230 meg repos would exceed my $20/month hosting account.
> Now a way to optimize this in darcs is to create checkpoints and let the
> contributers checkout only partial repositories. I put a checkpoint to
> the tag "v0_0_28". This adds about 1300 kB to the repository.
When I
> checkout that partial repository (onto anothe filesystem) I get a new
> repository:
> 
> Complete size: 11492 kB
> Size of _darcs (without _darcs/current): 1364 kB
A "checkpoint" and/or "partial repository" would basically
give you
history from a certain point forward, discarding any history from before 
that point, right?
> So the best way to optimize the space-usage for Windows-User would be to
> add checkpoints whenever the repository grows over a certain size. Not
> too much a burden if you ask me.
That might be ok, if we can figure out a smooth process to make it 
happen. I rarely look at history at all, and when I do it is usually 
only recent history.
> Some statistics over the scalability of darcs from one user:
> http://article.gmane.org/gmane.comp.version-control.darcs.user/7082
I agree that wxruby2 (and pretty much any project I would work on 
personally) would fall on the smaller end of the project spectrum, and 
thus would not face many darcs performance problems. I would like to 
hear some testimonials from MS Windows darcs users on medium-sized projects.
> BTW: So I already have done the CVS-to-darcs-thing, I can also put it
> online. I try to keep it current. The stuff is at
> http://darcs.portfolio16.de/wxruby2/ - use "darcs get --partial"
to only
> get the changes from the last tag till now.
This sounds cool, but the URL above gives a 403 Access Forbidden. Is it 
easy for you to make it publicly readonly?



There is one other drawback of repo-inside-working-tree: Bugfix 
releases. With darcs, if you release 1.0 and then 1.1 and then 1.0.1, 
there is no way to do so with a single public repo. You have to have a 
1.0.1 repo (that has none of the 1.1 work) and a 1.1 repo (that has none 
of the 1.0.1 work).

Hopefully we (wxruby2) won''t need many (if any) buxfix releases. But as
a project goes on longer and longer, the odds increase that you will 
need multiple bugfix releases. Those become more difficult to manage, as 
well as consuming excess bandwidth and server disk space. I suppose you 
could do bugfix releases as partials from the point they forked, but 
that''s one more manual intervention.

I like the simple model of repo-inside-working-tree, but fundamentally I 
believe it is flawed because it pushes too much mental burden onto 
developers. Computers are supposed to handle little bookkeeping things 
like that for us.

It might be possible to create a metadarcs wrapper that hid this 
complexity from developers. I haven''t thought it through yet.

Thanks for continuing the discussion, and I look forward to playing 
around with your darcs wxruby2 mirror.

Kevin

Hi again,

On Sat, Sep 03, 2005 at 05:35:46PM -0400, Kevin Smith
wrote:
> Tobias Gruetzmacher wrote:
> >On Mon, Aug 29, 2005 at 12:04:44AM -0400, Kevin Smith wrote:
> >
> >>I''m having second thoughts about darcs. The
repo-inside-working-tree
> >>model is really bad for MS Windows users. 
> >
> >This only becomes a problem when a Windows user wants to create
> >branches, right? So he has to make a full copy of his repository.
> 
> Right. Which in darcs is several times a day, if you are doing active 
> development. Sometimes several times within minutes of each other. For 
> example, today I probably would have wanted to create 10-20 branches 
> within about 2 hours. Each would have lasted perhaps 15 minutes before I 
> would have deleted it. Except one (in addition to the mainline) that I 
> would still have.
OK, point taken. Personally, I don''t work with that much branches, I
normally work only on one task at a time in one working copy. After
that, I can reuse it for the next feature, etc.
> Then there is network bandwidth, and server disk space. If we''re 
> encouraging people to host their own repos (which I want to do), then 
> those become issues. I''m not even sure how to calculate bandwidth,
but
> many hosting accounts are limited to tens or hundreds of megabytes. 
> Hosting even five 230 meg repos would exceed my $20/month hosting account.
There is an option in darcs which makes it posible to create
repositories which don''t have a checked out copy of the tree, so that
part would get a bit smaller.
> >Now a way to optimize this in darcs is to create checkpoints and let
the
> >contributers checkout only partial repositories. I put a checkpoint to
> >the tag "v0_0_28". This adds about 1300 kB to the repository.
When I
> >checkout that partial repository (onto anothe filesystem) I get a new
> >repository:
> >
> >Complete size: 11492 kB
> >Size of _darcs (without _darcs/current): 1364 kB
> 
> A "checkpoint" and/or "partial repository" would
basically give you
> history from a certain point forward, discarding any history from before 
> that point, right?
Yes.
> >So the best way to optimize the space-usage for Windows-User would be
to
> >add checkpoints whenever the repository grows over a certain size. Not
> >too much a burden if you ask me.
> 
> That might be ok, if we can figure out a smooth process to make it 
> happen. I rarely look at history at all, and when I do it is usually 
> only recent history.
If you do "Release early, release often", it may be sufficient to
checkpoint every release. That would be one switch more with every
release tag.
> >BTW: So I already have done the CVS-to-darcs-thing, I can also put it
> >online. I try to keep it current. The stuff is at
> >http://darcs.portfolio16.de/wxruby2/ - use "darcs get
--partial" to only
> >get the changes from the last tag till now.
> 
> This sounds cool, but the URL above gives a 403 Access Forbidden. Is it 
> easy for you to make it publicly readonly?
Umm, I had a hard disk problem with the server, you got me at the one
time where the server was up and the permissions of the files were
broken ;) Just try again.
> There is one other drawback of repo-inside-working-tree: Bugfix 
> releases. With darcs, if you release 1.0 and then 1.1 and then 1.0.1, 
> there is no way to do so with a single public repo. You have to have a 
> 1.0.1 repo (that has none of the 1.1 work) and a 1.1 repo (that has none 
> of the 1.0.1 work).
So if the bugfix is small enough, you can merge it from the one branch
to the other. I think that would be the prefered darcs working model.
You do the fix in your current development branch, see it may be good to
apply it to the stable releaes, and merge it there. This becomes a
problem if the development branch differs very much from the stable
version, so you have to do two patches.
> I like the simple model of repo-inside-working-tree, but fundamentally I 
> believe it is flawed because it pushes too much mental burden onto 
> developers. Computers are supposed to handle little bookkeeping things 
> like that for us.
Currently, I think the handling of checkpoint handling of darcs is a
little bit flawed: It can create multiple checkpoints, but can only use
the most recent one. I would like a darcs that would normaly only get
the latest checkpoint and automatically fetches older checkpoints as
there is need for older revisions...
> Thanks for continuing the discussion, and I look forward to playing 
> around with your darcs wxruby2 mirror.
Give it a shot, I''ve just pushed some more patches :)

Greetings Tobi

-- 
GPG-Key 0xE2BEA341 - signed/encrypted mail preferred
My, oh so small, homepage: http://portfolio16.de/
http://www.fli4l.de/ - ISDN- & DSL-Router on one disk!
Registered FLI4L-User #00000003
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://rubyforge.org/pipermail/wxruby-users/attachments/20050904/5ee14db0/attachment.bin

Tobias Gruetzmacher wrote:
> 
> Umm, I had a hard disk problem with the server, you got me at the one
> time where the server was up and the permissions of the files were
> broken ;) Just try again.
Ok. Works now.

I''m a bit confused, though. Looking at the "darcs changes",
it lists
only one checkin after the 0_0_25 tag, but the Changelog file has many 
entries after that. How are you syncing from CVS to darcs, and how 
confident are you that it is accurate? How often do you migrate new 
changes, and is that manual or automated? Do tags also get migrated 
automatically?
>>There is one other drawback of repo-inside-working-tree: Bugfix 
>>releases. With darcs, if you release 1.0 and then 1.1 and then 1.0.1, 
>>there is no way to do so with a single public repo. You have to have a 
>>1.0.1 repo (that has none of the 1.1 work) and a 1.1 repo (that has none
>>of the 1.0.1 work).
> 
> 
> So if the bugfix is small enough, you can merge it from the one branch
> to the other. 
Yes, you''re right. And darcs is MUCH better at moving changes between 
trees without conflicts than other SCM tools. My point was that you 
would be forced to have (and manage) a separate repo for each bugfix 
branch. That''s less convenient than tools like mercurial and ArX that 
allow a single repo to contain multiple branches.

So I still think that repo-inside-tree is the wrong model, and that if 
we start using darcs I will want to switch to something else later. 
However, based on another quick survey of the other tools, I really 
don''t see any tool meeting my requirements for this project within the 
next several months, at least.

Perhaps it would make sense to switch to darcs now, and just plan to 
switch to something else in a year or so. If something isn''t available 
by then, I my just have to write my own! In ruby, of course :-)

Thanks,

Kevin

Hi,

On Sun, Sep 04, 2005 at 03:18:39PM -0400, Kevin Smith
wrote:
> I''m a bit confused, though. Looking at the "darcs
changes", it lists
> only one checkin after the 0_0_25 tag, but the Changelog file has many 
> entries after that. How are you syncing from CVS to darcs, and how 
> confident are you that it is accurate? How often do you migrate new 
> changes, and is that manual or automated? Do tags also get migrated 
> automatically?
I just pointed the cvs2darcs script from the darcs homepage. Since it
uses cvsps to get patchsets/changesets from CVS, that would be to blame
if there is a problem. I verified once that the darcs and CVS tree are
the same after the import, but I (obviously) didn''t check every patch.
The CVS history of th Changelog looks very fishy to me...

I tried tailor, but coudn''t get that to work, so I only have a
one-way-mirror...

About migration: I used the cvs2darcs script once and now have a
directory that is both a CVS checkout and a darcs repository and I
update that manually in irregular intervals with the cvs2darcs main
script.
> Perhaps it would make sense to switch to darcs now, and just plan to 
> switch to something else in a year or so. If something isn''t
available
> by then, I my just have to write my own! In ruby, of course :-)
Another one? But as I see there really is none in Ruby at the moment :)

Greetings Tobi

-- 
GPG-Key 0xE2BEA341 - signed/encrypted mail preferred
My, oh so small, homepage: http://portfolio16.de/
http://www.fli4l.de/ - ISDN- & DSL-Router on one disk!
Registered FLI4L-User #00000003
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://rubyforge.org/pipermail/wxruby-users/attachments/20050904/5207a920/attachment.bin

Tobias Gruetzmacher wrote:
> I just pointed the cvs2darcs script from the darcs homepage. Since it
> uses cvsps to get patchsets/changesets from CVS, that would be to blame
> if there is a problem. I verified once that the darcs and CVS tree are
> the same after the import, but I (obviously) didn''t check every
patch.
> The CVS history of th Changelog looks very fishy to me...
Changelog was recently extracted out of README, so it has a short CVS 
history.

I just did a darcs pull, to get the latest stuff from your repo. 
Glancing at darcs changes and the Changelog, things now look fine. I''m 
not sure if something changed, or if I was just confused earlier.
> I tried tailor, but coudn''t get that to work, so I only have a
> one-way-mirror...
One way is fine for now, I think.
> About migration: I used the cvs2darcs script once and now have a
> directory that is both a CVS checkout and a darcs repository and I
> update that manually in irregular intervals with the cvs2darcs main
> script.
Would it be easy (or possible) for you to set up a cron job so the 
updates would happen automatically (predictably, reliably)? If you can 
do that, I will commit to accepting patches in darcs format, on an 
experimental basis.
>>Perhaps it would make sense to switch to darcs now, and just plan to 
>>switch to something else in a year or so. If something isn''t
available
>>by then, I my just have to write my own! In ruby, of course :-)
> 
> Another one? But as I see there really is none in Ruby at the moment :)
There is only one SCM tool in ruby (fastcst), and it is not mature 
enough to use. Since its author seems to have moved on to other projects 
(at least for now) I don''t have much hope for it.

Actually, there is one other Ruby SCM tool: yarcs. It was my attempt 
from a couple years ago to rewrite darcs into Ruby. I got it to the 
point where it could correcly "pull" and apply several hundred patches
from the darcs development repo. For a variety of reasons, I don''t want
to work on that project any more.

All I want is an SCM tool that has these features:
- Cross platform (Linux/Mac/MSWin)
- Truly cheap branching without hardlinks
- Reasonably simple UI
- Able to serve a readonly repo on a free/cheap http-only web host

So far, exactly NONE of the many tools out there can fulfill these 
minimal requirements. ArX fails #3. Codeville, monotone and svk fail #4. 
Darcs fails #2. Bzr (aka bazaar-ng aka bazaar2) currently fails #2, but 
the developers are actively discussing a solution. That''s why I remain 
optimistic that by next April (the 6.04 Ubuntu release) bzr may be the 
first system to meet all my needs. The next most likely appears to be 
ArX, if its author follows through with his UI simplification plans.

Seriously, if none of the systems have those features by a year from 
now, I may be forced to write my own, and if I do, you can bet that it 
will be in ruby. I really hope it doesn''t come to that. And at this 
point it looks like it won''t.

Kevin

Hi,

On Thu, Sep 08, 2005 at 09:00:04PM -0400, Kevin Smith
wrote:
> Would it be easy (or possible) for you to set up a cron job so the 
> updates would happen automatically (predictably, reliably)? If you can 
> do that, I will commit to accepting patches in darcs format, on an 
> experimental basis.
I came around building a secure setup with automatic updates via cron.
The update happens every night at 03:30 CET/CEST. It pushes from my home
server to the server darcs.portfolio16.de, that should work most of the
time...

Greetings Tobi

-- 
GPG-Key 0xE2BEA341 - signed/encrypted mail preferred
My, oh so small, homepage: http://portfolio16.de/
http://www.fli4l.de/ - ISDN- & DSL-Router on one disk!
Registered FLI4L-User #00000003
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://rubyforge.org/pipermail/wxruby-users/attachments/20050930/57a3f8ec/attachment.bin

Tobias Gruetzmacher wrote:
> I came around building a secure setup with automatic updates via cron.
> The update happens every night at 03:30 CET/CEST. It pushes from my home
> server to the server darcs.portfolio16.de, that should work most of the
> time...
Cool. I grabbed a copy, and it looks good.

Now, big question: Who will submit patches in darcs format? Roy? Sean? 
As the two most active contributors at the moment, are either or both of 
you ready, able, and willing to try out darcs?

I haven''t yet figured out how the process will actually work, so I
would
suggest that anyone interested should pull the wxruby2 repo into darcs, 
but not actually submit any patches until I have applied all the pending 
patches that have already been sent.

Everyone may have noticed that I have been quiet around here lately. 
Sorry about that! I see that I have several patches more than a week 
old, which I feel very bad about. Hopefully I''ll be able to integrate 
those over the weekend. Switching to something like darcs or bzr should 
not only make my work easier, but should also take some pressure off 
because it will be less critical that I merge patches promptly all the time.

Next, I suggest that we try just a patch or two via darcs first, to make 
sure the workflow isn''t terribly broken. I am a bit concerned that 
mixing CVS and darcs may actually cause problems, so we might have to 
decide to jump completely to darcs now, perhaps continuing to publish 
the CVS repository as a readonly mirror of the official public darcs 
wxruby repo.

As I mentioned before, darcs requires some self-discipline. Here are my 
recommendations for how to set up wxruby2 under darcs on your machine. 
Note, sadly, that it is late at night and I''m trying to rush off to
bed,
so I haven''t actually tested these exact commands. Hopefully they are
at
least very close to accurate.

First, create a master umbrella wxruby2 directory that will itself 
contain two or more copies of wxruby. From that master directory, issue 
these commands:

   darcs get http://darcs.portfolio16.de pulled

That will create an exact copy of portfolio16 in your "pulled" repo.
The
"pulled" directory should always be an exact copy of the remote mirror
on portfolio16. This may seem silly, but it''s actually quite valuable. 
Then do:

   darcs get pulled work

That will create your own working copy, named "work". You will do your
editing and compiling in your work repo. Before you start each coding 
session, change into the pulled directory and do:

   darcs pull

That should update your pulled directory to match the portfolio16 repo. 
Then, go to your work repo and do:

   darcs pull

That will merge the latest official changes into your work repo.

After you have checked in your changes, there are two ways you can 
submit your patches to me:

1. use some variant of "darcs send" (from inside the work repo)
2. publish your own darcs wxruby2 repo on a public web host

If you are going to work on two unrelated things at the same time, you 
might want to create additional repos, one per major task. It will take 
some practice and experience to figure out exactly how to be most 
productive.

Kevin

I am willing to give it a try. Sounds like we will all learn together,
a recipe for disaster ;)

Sean

On 9/30/05, Kevin Smith <wxruby at qualitycode.com>
wrote:
> Tobias Gruetzmacher wrote:
> > I came around building a secure setup with automatic updates via cron.
> > The update happens every night at 03:30 CET/CEST. It pushes from my
home
> > server to the server darcs.portfolio16.de, that should work most of
the
> > time...
>
> Cool. I grabbed a copy, and it looks good.
>
> Now, big question: Who will submit patches in darcs format? Roy? Sean?
> As the two most active contributors at the moment, are either or both of
> you ready, able, and willing to try out darcs?
>
> I haven''t yet figured out how the process will actually work, so I
would
> suggest that anyone interested should pull the wxruby2 repo into darcs,
> but not actually submit any patches until I have applied all the pending
> patches that have already been sent.
>
> Everyone may have noticed that I have been quiet around here lately.
> Sorry about that! I see that I have several patches more than a week
> old, which I feel very bad about. Hopefully I''ll be able to
integrate
> those over the weekend. Switching to something like darcs or bzr should
> not only make my work easier, but should also take some pressure off
> because it will be less critical that I merge patches promptly all the
time.
>
> Next, I suggest that we try just a patch or two via darcs first, to make
> sure the workflow isn''t terribly broken. I am a bit concerned that
> mixing CVS and darcs may actually cause problems, so we might have to
> decide to jump completely to darcs now, perhaps continuing to publish
> the CVS repository as a readonly mirror of the official public darcs
> wxruby repo.
>
> As I mentioned before, darcs requires some self-discipline. Here are my
> recommendations for how to set up wxruby2 under darcs on your machine.
> Note, sadly, that it is late at night and I''m trying to rush off
to bed,
> so I haven''t actually tested these exact commands. Hopefully they
are at
> least very close to accurate.
>
> First, create a master umbrella wxruby2 directory that will itself
> contain two or more copies of wxruby. From that master directory, issue
> these commands:
>
>    darcs get http://darcs.portfolio16.de pulled
>
> That will create an exact copy of portfolio16 in your "pulled"
repo. The
> "pulled" directory should always be an exact copy of the remote
mirror
> on portfolio16. This may seem silly, but it''s actually quite
valuable.
> Then do:
>
>    darcs get pulled work
>
> That will create your own working copy, named "work". You will do
your
> editing and compiling in your work repo. Before you start each coding
> session, change into the pulled directory and do:
>
>    darcs pull
>
> That should update your pulled directory to match the portfolio16 repo.
> Then, go to your work repo and do:
>
>    darcs pull
>
> That will merge the latest official changes into your work repo.
>
> After you have checked in your changes, there are two ways you can
> submit your patches to me:
>
> 1. use some variant of "darcs send" (from inside the work repo)
> 2. publish your own darcs wxruby2 repo on a public web host
>
> If you are going to work on two unrelated things at the same time, you
> might want to create additional repos, one per major task. It will take
> some practice and experience to figure out exactly how to be most
> productive.
>
> Kevin
> _______________________________________________
> wxruby-users mailing list
> wxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>

> First, create a master umbrella wxruby2 directory that will itself
> contain two or more copies of wxruby. From that master directory, issue
> these commands:
>
>    darcs get http://darcs.portfolio16.de pulled
>
should be:

darcs get http://darcs.portfolio16.de/wxruby2 pulled

Notes:
- Slow download when doing copying patch ? of 242
- The applying patches part is slow and very CPU intensive. (running
on Dual 1.25 G4''s)
- Overall about 3 to 4 times slower than a cvs co wxruby2

Sean

I sent a small trivial patch to see how the process works, hopefully
you will receive it.

Sean

Sean Long wrote:
 > I am willing to give it a try. Sounds like we will all learn together,
 > a recipe for disaster  ;)

Excellent.
> should be:
> 
> darcs get http://darcs.portfolio16.de/wxruby2 pulled
Absolutely. Thanks for the correction. Perhaps someone could copy the 
instructions to the wiki so they can remain up-to-date. I''m having some
second thoughts about the name "pulled", too.
> Notes:
> - Slow download when doing copying patch ? of 242
Yes, I saw a hiccup around patch 200. I suspect that was when we dropped 
the XML extraction and removed all the src/ files, creating a very large 
darcs patch.
> - The applying patches part is slow and very CPU intensive. (running
> on Dual 1.25 G4''s)
> - Overall about 3 to 4 times slower than a cvs co wxruby2
Yes, darcs is known for being slow, CPU intensive, and a memory hog, at 
times. Fortunately, you should rarely have to do a full darcs get. For 
normal operations, darcs should be reasonable on a small project like ours.

I still hope to switch to bzr (or perhaps something else) in a few 
months, and it would likely be faster than darcs.

 > I sent a small trivial patch to see how the process works,
 > hopefully you will receive it.

Hm. I have not seen it yet.

Kevin

I''ll check out the darcs server soon and see how I like it.

FYI, I found this on the SWIG CVS:

09/24/2005: cfisavage
            [Ruby] Adds new %trackobjects functionality that maps C++ objects to
            Ruby objects.  This functionality makes it much easier to implement
            mark functions for the garbage collector.  For more information
            refer to the update documentation and examples.

This could be good for us.

Roy

Kevin Smith wrote:
> Tobias Gruetzmacher wrote:
>   
>> I came around building a secure setup with automatic updates via cron.
>> The update happens every night at 03:30 CET/CEST. It pushes from my
home
>> server to the server darcs.portfolio16.de, that should work most of the
>> time...
>>     
>
> Cool. I grabbed a copy, and it looks good.
>
> Now, big question: Who will submit patches in darcs format? Roy? Sean? 
> As the two most active contributors at the moment, are either or both of 
> you ready, able, and willing to try out darcs?
>
> I haven''t yet figured out how the process will actually work, so I
would
> suggest that anyone interested should pull the wxruby2 repo into darcs, 
> but not actually submit any patches until I have applied all the pending 
> patches that have already been sent.
>
> Everyone may have noticed that I have been quiet around here lately. 
> Sorry about that! I see that I have several patches more than a week 
> old, which I feel very bad about. Hopefully I''ll be able to
integrate
> those over the weekend. Switching to something like darcs or bzr should 
> not only make my work easier, but should also take some pressure off 
> because it will be less critical that I merge patches promptly all the
time.
>
> Next, I suggest that we try just a patch or two via darcs first, to make 
> sure the workflow isn''t terribly broken. I am a bit concerned that
> mixing CVS and darcs may actually cause problems, so we might have to 
> decide to jump completely to darcs now, perhaps continuing to publish 
> the CVS repository as a readonly mirror of the official public darcs 
> wxruby repo.
>
> As I mentioned before, darcs requires some self-discipline. Here are my 
> recommendations for how to set up wxruby2 under darcs on your machine. 
> Note, sadly, that it is late at night and I''m trying to rush off
to bed,
> so I haven''t actually tested these exact commands. Hopefully they
are at
> least very close to accurate.
>
> First, create a master umbrella wxruby2 directory that will itself 
> contain two or more copies of wxruby. From that master directory, issue 
> these commands:
>
>    darcs get http://darcs.portfolio16.de pulled
>
> That will create an exact copy of portfolio16 in your "pulled"
repo. The
> "pulled" directory should always be an exact copy of the remote
mirror
> on portfolio16. This may seem silly, but it''s actually quite
valuable.
> Then do:
>
>    darcs get pulled work
>
> That will create your own working copy, named "work". You will do
your
> editing and compiling in your work repo. Before you start each coding 
> session, change into the pulled directory and do:
>
>    darcs pull
>
> That should update your pulled directory to match the portfolio16 repo. 
> Then, go to your work repo and do:
>
>    darcs pull
>
> That will merge the latest official changes into your work repo.
>
> After you have checked in your changes, there are two ways you can 
> submit your patches to me:
>
> 1. use some variant of "darcs send" (from inside the work repo)
> 2. publish your own darcs wxruby2 repo on a public web host
>
> If you are going to work on two unrelated things at the same time, you 
> might want to create additional repos, one per major task. It will take 
> some practice and experience to figure out exactly how to be most 
> productive.
>
> Kevin
> _______________________________________________
> wxruby-users mailing list
> wxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>
>
>
>

>  > I sent a small trivial patch to see how the process works,
>  > hopefully you will receive it.
>
> Hm. I have not seen it yet.
I did a darcs send and entered your email, oh well. I just did a darcs
send -o filename and am including that in this message. Let me know if
that is how you want patches from darcs.


Sean
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bundle
Type: application/octet-stream
Size: 2401 bytes
Desc: not available
Url :
http://rubyforge.org/pipermail/wxruby-users/attachments/20051001/e11276ee/bundle.obj

>09/24/2005: cfisavage
>            [Ruby] Adds new %trackobjects functionality that maps C++
objects to
>            Ruby objects.  This functionality makes it much easier to
implement
>            mark functions for the garbage collector.  For more information
>            refer to the update documentation and examples.
>  
>
Charlie savage started a comp.lang.ruby thread on this a month or two 
ago which did sound relevant to our problem.

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/152816

a

Hi,

On Sat, Oct 01, 2005 at 08:47:14AM -0400, Kevin Smith
wrote:
> > Notes:
> > - Slow download when doing copying patch ? of 242
> 
> Yes, I saw a hiccup around patch 200. I suspect that was when we dropped 
> the XML extraction and removed all the src/ files, creating a very large 
> darcs patch.
You can accelerate the whole progress by only getting a partial
repository (from the last TAG on):

darcs get --partial http://darcs.portfolio16.de/wxruby2 pulled

I hope the darcs people make that the default in some upcoming version
and let the client pull older patches only when they are needed...

Greetings Tobi

-- 
GPG-Key 0xE2BEA341 - signed/encrypted mail preferred
My, oh so small, homepage: http://portfolio16.de/
http://www.fli4l.de/ - ISDN- & DSL-Router on one disk!
Registered FLI4L-User #00000003
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://rubyforge.org/pipermail/wxruby-users/attachments/20051002/5ac542ba/attachment.bin

Well, I just did this and it was -fast-.  I think this was much faster 
than my old method of downloading a tarball from the CVS repository.  
And, I won''t ever have to pull the whole thing again, theoretically.

Roy

Tobias Gruetzmacher wrote:
> You can accelerate the whole progress by only getting a partial
> repository (from the last TAG on):
>
> darcs get --partial http://darcs.portfolio16.de/wxruby2 pulled

I hope no one minds I wrote to Charlie to ask if he might help us get 
his changes incorporated into our source so that we can benefit before 
the official SWIG release comes out.  I''m hoping he might be able to 
shed some light on some of the other problems we''ve been having.

Roy

Alex Fenton wrote:
>> 09/24/2005: cfisavage
>>            [Ruby] Adds new %trackobjects functionality that maps C++
objects to
>>            Ruby objects.  This functionality makes it much easier to
implement
>>            mark functions for the garbage collector.  For more
information
>>            refer to the update documentation and examples.
>>  
>>
>>     
> Charlie savage started a comp.lang.ruby thread on this a month or two 
> ago which did sound relevant to our problem.
>
> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/152816
>
> a
> _______________________________________________
> wxruby-users mailing list
> wxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>
>
>
>

Roy Sutton wrote:
> I hope no one minds I wrote to Charlie to ask if he might help us get 
> his changes incorporated into our source so that we can benefit before 
> the official SWIG release comes out.  I''m hoping he might be able
to
> shed some light on some of the other problems we''ve been having.
Sounds great. Based on the description he posted to the SWIG mailing 
list, it sounds like he''s doing something similar to what we are doing.
It would be great to know if his approach is inherently better (aside 
from being built into SWIG itself).

As you may have guessed, I don''t think we will be able to require SWIG 
1.3.26 (which will have the new feature) for at least several months 
after it is released.

Hmmmm. His posting on the SWIG list called it %DISOWN, but this says 
%trackobjects. Must have changed in the process of getting integrated 
into the official tree.

Kevin

Tobias Gruetzmacher wrote:
> You can accelerate the whole progress by only getting a partial
> repository (from the last TAG on):
> 
> darcs get --partial http://darcs.portfolio16.de/wxruby2 pulled
Cool. Since I don''t plan to do remote pulls very often, I found the 
speed to be acceptable. I think it took a few minutes to get everything. 
I didn''t pay close attention, but I watched the progress rather than 
leaving the room, so it must not have taken TOOO long. Theoretically, I 
should never need to do that again, as I will just be doing incremental 
pulls from now on.

Thanks,

Kevin

Kevin Smith wrote:
> Roy Sutton wrote:
>   
>> I hope no one minds I wrote to Charlie to ask if he might help us get 
>> his changes incorporated into our source so that we can benefit before 
>> the official SWIG release comes out.  I''m hoping he might be
able to
>> shed some light on some of the other problems we''ve been
having.
>>     
>
> Sounds great. Based on the description he posted to the SWIG mailing 
> list, it sounds like he''s doing something similar to what we are
doing.
> It would be great to know if his approach is inherently better (aside 
> from being built into SWIG itself).
>   
Well, I don''t think we''ve actually tackled that issue yet. 
It''s on the
TODO list.  As he''s already done the work I don''t see why
we''d want to
reinvent the wheel.
> As you may have guessed, I don''t think we will be able to require
SWIG
> 1.3.26 (which will have the new feature) for at least several months 
> after it is released.
>   
I already figured this out.  My bet is we can extract his .SWG file 
changes and optionally include them if SWIGVER < 1.3.26.  I specifically 
asked him about this.  It turns out my earlier e-mail to him was 
spam-filtered and the auto-spam-filter response was spam-filtered on my 
end.  So, we didn''t touch base until just about an hour or so
ago.
> Hmmmm. His posting on the SWIG list called it %DISOWN, but this says 
> %trackobjects. Must have changed in the process of getting integrated 
> into the official tree.
>   
Two different features.  %DISOWN allows you to move ownership of the 
object.  For example, if you set a an object that becomes owned by the 
window you''ll want ruby to let go of its hold on it so it gets freed 
properly by the window.  The track objects stuff is a related, but 
different, feature that ensures that any time you request a wrapper for 
a C++ object you get the same ruby object back.

Roy

Kevin Smith wrote:
> Sean Long wrote:
>>
>>darcs get http://darcs.portfolio16.de/wxruby2 pulled
> 
> Absolutely. Thanks for the correction. Perhaps someone could copy the 
> instructions to the wiki so they can remain up-to-date. I''m having
some
> second thoughts about the name "pulled", too.
My revised proposal is to name that directory "pristine", instead of 
"pulled". That is, it represents a pristine, pulled copy of the remote
mirror of the official wxruby2 archives (whew!). Hopefully with the name 
"pristine", you''ll remember to never actually do any work in
there.
Always make a local clone for your work. In pristine, only do pulls.
>  > I sent a small trivial patch to see how the process works,
>  > hopefully you will receive it.
I got the second copy you sent. I haven''t yet tried to do anything to 
it, because my darcs pristine repo is out-of-date. Of course it is, 
because I just checked a bunch of stuff into CVS, and it hasn''t been 
mirrored yet. Bummer that the mirroring only happens once a day, but
I''m
VERY grateful that we HAVE a remote darcs mirror, so I''m not
complaining!

Eventually, assuming we continue using darcs, we will either update the 
darcs repo before CVS, at the same time as CVS, or at least very soon 
after CVS.

Any discussions of darcs process will be a bit cloudy, because MY 
process (as project maintainer) will necessarily be quite different than 
yours (as contributors). What follows is a somewhat lengthy brain dump. 
Hopefully those of you who are interested in darcs will be able to 
follow along, and perhaps offer suggestions, critiques, etc.

I''m imagining that contributors will be able to ignore CVS entirely,
and
work purely in darcs. You will have your pristine repo, and pull into it 
frequently (at least at the beginning of each coding session). Then, you 
will clone pristine into one or more local working repos where you will 
actually edit, compile, and test.

When you''re happy with your results, you will "record" your
changes into
your working darcs repo, and eventually you will either send (email) 
your patch bundle to me, or will publish your own repo(s) on the web. I 
think I said all that before.

My "maintainer" process, at least for now, will still include CVS. I 
will keep my current working directory which is set up to commit into 
CVS, but I won''t do any actual work in it. I will also have a darcs 
pristine repo (regularly pulled from portfolio16).

When I want to apply a submitted darcs patch, I will clone the pristine 
repo, and apply the patch into the clone. In the clone repo, I will 
examine the patch, compile, and test the results. I will also make any 
necessary edits, and will update the Changelog[1].

When I am happy with the changeset, I will use "meld" to diff the
cloned
repo against my "official" local CVS working directory. I will
manually
move all new or changed files, and will delete any that have been 
deleted. It''s pretty easy with a point-and-click gui. Then, I will do a
cvs commit.

Because the remote mirror won''t update immediately, I will have to 
continue using the same cloned repo for an entire session of patch 
applying. Well, actually I''ll clone it again after each CVS commit, to 
allow me to easily roll back if I don''t like a changeset.

Probably at the start of my next session, I would re-pull into pristine, 
and then delete all the clones.

Here''s one thing I haven''t figured out: darcs tends to be
REALLY picky
about patch identity. If you have two identical trees, but those trees 
don''t have identical patch history, you can''t easily merge
between them.
I believe this issue is specific to darcs, and would not affect bzr (or 
mercurial, or most of the others). A similar (but not identical) problem 
might happen with ArX.

As a simple example, imagine if Adam grabbed the portfolio16 copy of 
wxruby2, but Eve instead grabbed today''s CVS snapshot, and did a darcs 
init to turn it into a repo. If they email patches to each other, those 
patches would not apply. Darcs would not recognize that the two trees 
are at all related, even though they are identical.

So, now imagine that Carl pulls the latest darcs repo, creates a cloned 
repo named "working", makes changes, and emails those patches to me. I
commit them to CVS, and the changes get mirrored and then pulled into 
Carl''s pristine tree. If Carl tries to merge between pristine and his
"working" repo, I''m not sure what will happen. Darcs might
refuse to
apply the official patch, or might consider it to be a conflict. 
Hopefully it will be smart enough to see the contents are identical, and 
just do a silent merge.

But what if I made some changes? Will darcs still do a good merge? And 
will darcs be flustered constantly trying to sync Carl''s original
change
which never makes it into the official repo? Will it be possible for 
someone to maintain a long-lived "tracking" repo that has some local 
changes that aren''t in pristine yet? A good example of this would be 
Roy''s ongoing scintilla work.

So hopefully tomorrow I''ll be able to apply Sean''s test darcs
patch. And
then Sean can tell us how well it came back into his darcs repo.

It''s definitely going to be a learning experience.

Kevin

Roy Sutton wrote:
> Kevin Smith wrote:
> 
>>
>>Sounds great. Based on the description he posted to the SWIG mailing 
>>list, it sounds like he''s doing something similar to what we
are doing.
>>It would be great to know if his approach is inherently better (aside 
>>from being built into SWIG itself).
>>  
> Well, I don''t think we''ve actually tackled that issue
yet.  It''s on the
> TODO list.  As he''s already done the work I don''t see why
we''d want to
> reinvent the wheel.
See below...
> I already figured this out.  My bet is we can extract his .SWG file 
> changes and optionally include them if SWIGVER < 1.3.26.  
Sounds great.
> Two different features.  %DISOWN allows you to move ownership of the 
> object.  For example, if you set a an object that becomes owned by the 
> window you''ll want ruby to let go of its hold on it so it gets
freed
> properly by the window.  The track objects stuff is a related, but 
> different, feature that ensures that any time you request a wrapper for 
> a C++ object you get the same ruby object back.
Ah. Ok. Now I see. The original description of %trackobjects sounded 
more like %DISOWN. I was focused on the reference to "mark", which
would
be to avoid crashing when a C++ object was deleted without Ruby knowing 
about it. Unfortunately, it''s not clear that Charlie''s %DISOWN
solution
will be any better than ours, since ours already works well for any 
class that actually has a director.

The interesting bit of the %trackobjects stuff is the ability to return 
the same Ruby object that was passed in. It would definitely be great to 
use Charlies work on this, since as you suggest, we haven''t tackled it 
yet in wxruby2. We did have this in wxruby 0.6, so it wouldn''t be all 
that hard, but I''m much happier using an "official" solution.

Thanks,

Kevin

Sean Long wrote:
> I did a darcs send and entered your email, oh well. I just did a darcs
> send -o filename and am including that in this message. Let me know if
> that is how you want patches from darcs.
Thanks for sending that sample patch! For the curious, it just tweaked a 
line of text in the TODO file...cleverly, the one mentioning switching 
to darcs :-)

After I used "darcs apply", I was momentarily baffled because
"darcs
whatsnew" reported that nothing had changed. Then I realized that the 
patch had been applied to both the working copy and to the darcs repo. I 
confirmed that Sean''s patch was in my darcs changelog. And a directory 
comparison with my pristine tree showed the change.

Then I used meld to compare my darcs working copy against my long-time 
CVS wxruby2 directory. With two clicks, I copied the modified file into 
my CVS staging tree. I then edited Changelog, and did a cvs commit. So 
the darcs-generated and darcs-applied patch is now in the cvs tree.

Sean: I''m really interested to hear what happens when you try to darcs 
pull this patch into the repo from which it was generated. After the 
change gets copied to the darcs mirror, of course.

So, the format you used to email me the darcs patch was great. If you 
have a way of naming the attachment something more specific than 
"bundle", that would be appreciated, but not essential.

Again, thanks.

Kevin

> Sean: I''m really interested to hear what happens when you try to
darcs
> pull this patch into the repo from which it was generated. After the
> change gets copied to the darcs mirror, of course.
Changes not copied to mirror yet, will try later.
> So, the format you used to email me the darcs patch was great. If you
> have a way of naming the attachment something more specific than
> "bundle", that would be appreciated, but not essential.
what I did was:
darcs record
darcs send -o bundle

so bundle can be replaced with any file name like wxGrid_mega_fix.patch

Sean

Sean Long wrote:
> Changes not copied to mirror yet, will try later.
Right. The mirror is scheduled for 3:30AM CET/CEST, which is UTC + 1/2, 
whereas I''m in EST/EDT (UTC - 5/4), so I guess for me it would happen
at
9:30pm each evening, which is often right before I start working on wxruby.
> what I did was:
> darcs record
> darcs send -o bundle
Wow. That''s pretty darned simple.
> so bundle can be replaced with any file name like wxGrid_mega_fix.patch
That would be great. I tend to accumulate the patch files in a directory 
for a single session (typically an evening), and then erase them all 
before starting the next batch. So the names don''t need to be globally 
unique, but a short meaningful name like that would be helpful.

Thanks,

Kevin

> Sean: I''m really interested to hear what happens when you try to
darcs
> pull this patch into the repo from which it was generated. After the
> change gets copied to the darcs mirror, of course.
I finally did this and got this in my repo:

Pulling from "/Users/sean/work/wxruby2/pulled"...

Wed Oct  5 20:21:57 PDT 2005  qualitycode
  * Applied a test patch (to the TODO file) submitted via darcs (Sean Long)
Shall I pull this patch? (1/1) [ynWvpxqadjk], or ? for help: y

We have conflicts in the following files:
./TODO
Finished pulling and applying.

This is what the TODO looked like (I don''t think I touched this file
after sending the patch). The vv and ^^ are inserted by darcs.

v v v v v v v
- Switch from CVS to darcs? (in progress)
^ ^ ^ ^ ^ ^ ^

Maybe we need some parameters to darcs send, it does have a -u like diff.

Sean

Sean Long wrote:
>>Sean: I''m really interested to hear what happens when you try
to darcs
>>pull this patch into the repo from which it was generated. After the
>>change gets copied to the darcs mirror, of course.
> 
> 
> I finally did this and got this in my repo:
> 
> Pulling from "/Users/sean/work/wxruby2/pulled"...
> 
> Wed Oct  5 20:21:57 PDT 2005  qualitycode
>   * Applied a test patch (to the TODO file) submitted via darcs (Sean Long)
> Shall I pull this patch? (1/1) [ynWvpxqadjk], or ? for help: y
> 
> We have conflicts in the following files:
> ./TODO
> Finished pulling and applying.
> 
> This is what the TODO looked like (I don''t think I touched this
file
> after sending the patch). The vv and ^^ are inserted by darcs.
> 
> v v v v v v v
> - Switch from CVS to darcs? (in progress)
> ^ ^ ^ ^ ^ ^ ^
Bummer. That''s basically what I feared. Darcs doesn''t quite
notice that
the patch you sent me, and the patch I sent you back perform identical 
changes. It inserts the vvv ^^^ to indicate where those two patches 
"conflicted", even though the outcome was identical.
> Maybe we need some parameters to darcs send, it does have a -u like diff.
I don''t think that would help.

This won''t be a problem as long as you (all of you who are
contributors,
that is) throw away each working repos after all of its submitted 
patches have been applied. In this case, you would have created the 
working repo, made the change, submitted the patch, received my version 
of that patch into your pristine tree, confirmed that my change was at 
least as good as yours, and then deleted that working repo.

I can think of at least two drawbacks of that process:

1. You will have to somehow confirm that my change is as good as yours. 
If they are identical, you can look for a pattern like the one you saw 
here...perhaps that could even be automated. If they changes are 
different, you will need to manually inspect each case where my change 
was different from yours. I think that''s slightly worse than what you 
have been doing with CVS, but maybe not?

2. If you have a long-lived working repo (branch) that contains a mix of 
accepted and not-yet-accepted patches, you will have to manually 
reconcile the accepted patches. I guess that''s not too horrible as long
as you avoid doing lots of work there that gets accepted. If it all gets 
accepted, the repo can go away. If none is accepted, there won''t be 
conflicts. If some is accepted once, but the rest is not accepted for a 
while, you''ll only have to do this resolution that one time. Again, 
perhaps this is no worse than with CVS?

The "solution", of course, would be for me to directly publish a darcs
repo, rather than having the darcs repo be a mirror of changes pushed 
via CVS. I would like to get more experience with darcs before 
attempting that. And we would have to decide whether or not to continue 
offering a read-only CVS mirror of the darcs work.

For now, I would like to try a couple more darcs patch submissions, and 
then we can decide on next steps.

Thanks again,

Kevin