Rubyinstaller devel - Apr 2008 - RFC: Version Control for new Installer?

Hello fellow developers,

It seems I neglected to push or decide what to do regarding the code
being developed for what I call it ''installer3'' MinGW build.

So far, the idea was push these changes back into svn, which will
lower the entry point for others developers wanting to contribute back
to it.

Since ''git'' is the new cool toy, I wondered a lot of
Installer3 should
also move to it, even when Git support is not 100% what I will love to
have.

Or, instead, I was thinking also move the repo from my host to
launchpad, which will raise some critics about using closed-source
software to host an open source project (github is closed source
anyway)...

What do you guys think will be best? I''m open to suggestions.

What I love of the dvcs workflow is that I can keep local branches to
foster experimentation and try new things before I merge them back
cherry pick stuff from them.

Thank you for your time guys, feel free to comment.
-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

SVN has the lowest barrier to entry for Win32 developers (Collabnet''s 
SVN installer for Windows, TortoiseSVN).

To the best of knowledge, all the other tools (bzr, git, etc) do not 
have a stable, native win32 client. That is, they all require an 
existing Cygwin or MinGW install.

The other benefit of SVN is that if folks want to use git, git-svn can 
push their changes back to the SVN repo.

Given that this is a Win32 project for Win32 developers, my vote is for SVN.

=Will Green

Luis Lavena wrote:
> Hello fellow developers,
>
> It seems I neglected to push or decide what to do regarding the code
> being developed for what I call it ''installer3'' MinGW
build.
>
> So far, the idea was push these changes back into svn, which will
> lower the entry point for others developers wanting to contribute back
> to it.
>
> Since ''git'' is the new cool toy, I wondered a lot of
Installer3 should
> also move to it, even when Git support is not 100% what I will love to
> have.
>
> Or, instead, I was thinking also move the repo from my host to
> launchpad, which will raise some critics about using closed-source
> software to host an open source project (github is closed source
> anyway)...
>
> What do you guys think will be best? I''m open to suggestions.
>
> What I love of the dvcs workflow is that I can keep local branches to
> foster experimentation and try new things before I merge them back
> cherry pick stuff from them.
>
> Thank you for your time guys, feel free to comment.
>

On Wed, Apr 23, 2008 at 9:01 AM, Will Green <will at hotgazpacho.org>
wrote:
> SVN has the lowest barrier to entry for Win32 developers
(Collabnet''s
>  SVN installer for Windows, TortoiseSVN).
>
Good points. Even I have installed TortoiseSVN, no longer uses it due
some memory consumption that imposes on explorer.exe....

Anyway...
>  To the best of knowledge, all the other tools (bzr, git, etc) do not
>  have a stable, native win32 client. That is, they all require an
>  existing Cygwin or MinGW install.
>
On that topic, based in my personal experience. Bzr was one, if not
the only one that worked out of the box, using the standalone version
or the python packages. but as you state, there are no "stable"
releases or sometimes requires fulfill dependencies that can make
things a bit harder for developers.
>  The other benefit of SVN is that if folks want to use git, git-svn can
>  push their changes back to the SVN repo.
>
Right know I''m using bzr-svn which perform similar operations that
git-svn, so I''m good with that.
>  Given that this is a Win32 project for Win32 developers, my vote is for
SVN.
>
Then I''ll push the changes back into existing repo (but it''s
own
branch), and keep git or bzr for local workflow only.

Thank you for your comments Will,
.
-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

I''m a recent converted from CVS to Git, and find it very nice.

One of its advantages is precisely what Luis mentions, to have the
ability to create local experimental branches without impacting the
main repository, and cherry-picking what you want.

github.com helps open source projects to get even more exposure which
is a good thing, getting attention and potentially getting more
contributions back. Nothing that I can scientifically prove though.

AFAIK, there''s a Git version for MSYS. According to my logic book,
since installer3 will run on MSYS, it doesn''t feel wrong to use
msysgit, which is already used in production environments (according
to its Wikipedia entry).

And more importantly, I don''t like SVN and its long list of
dependencies :-)

That''s my biased opinion, for whatever it''s worth.

-- 
Gerardo Santana

On Wed, Apr 23, 2008 at 12:59 PM, Gerardo Santana G?mez Garrido
<gerardo.santana at gmail.com> wrote:
> I''m a recent converted from CVS to Git, and find it very nice.
>
Still get confused due the high quantity of commands available and the
huge amount of combos to get simple things going... That''s what I call
a bad UI versus a good UI...
>  One of its advantages is precisely what Luis mentions, to have the
>  ability to create local experimental branches without impacting the
>  main repository, and cherry-picking what you want.
>
>  github.com helps open source projects to get even more exposure which
>  is a good thing, getting attention and potentially getting more
>  contributions back. Nothing that I can scientifically prove though.
>
I''m not 100% positive abut github. Like Zed wasn''t with the
move of
the svn repository outside rubyforge. We could better use gitorius [1]
instead of a closed source implementation, like if we go for LaunchPad
instead.

Even we have a full repo that can be relocated/pushed to another
hosting/site. I found quite annoying the relocation of repositories of
OSS projects.
>  AFAIK, there''s a Git version for MSYS. According to my logic
book,
>  since installer3 will run on MSYS, it doesn''t feel wrong to use
>  msysgit, which is already used in production environments (according
>  to its Wikipedia entry).
>
Well, I mention msysGit in the original mail, basically it works,
still it misses a few bits but works. Still, we should keep using the
SVN repo at least for users already using Subversion at their
companies or working with other open-source projects that want to
contribute back, at least with patches.

What we do with MSYS is quite different of what Git does. we only use
it for make and sh (bash) to get compatible support for configure
scripts and generated makefiles.

On the other hand, msysGit have it''s own copy that I wouldn''t
touch
since could break something :-P
>  And more importantly, I don''t like SVN and its long list of
dependencies :-)
>
We wouldn''t be building svn from scratch, trust me, I''ll not
go that
path... tried several times (more than 15 times) and failed all of
them.
>  That''s my biased opinion, for whatever it''s worth.
>
Not biased, but valid. Is good to know there are users in Windows
using Git, and I''ll love to heard back regarding it''s usage.

-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

On Wed, Apr 23, 2008 at 11:10 AM, Luis Lavena <luislavena at gmail.com>
wrote:
> On Wed, Apr 23, 2008 at 12:59 PM, Gerardo Santana G?mez Garrido
>  <gerardo.santana at gmail.com> wrote:
>  > I''m a recent converted from CVS to Git, and find it very
nice.
>  >
>
>  Still get confused due the high quantity of commands available and the
>  huge amount of combos to get simple things going... That''s what I
call
>  a bad UI versus a good UI...
>
>
>  >  One of its advantages is precisely what Luis mentions, to have the
>  >  ability to create local experimental branches without impacting the
>  >  main repository, and cherry-picking what you want.
>  >
>  >  github.com helps open source projects to get even more exposure
which
>  >  is a good thing, getting attention and potentially getting more
>  >  contributions back. Nothing that I can scientifically prove though.
>  >
>
>  I''m not 100% positive abut github. Like Zed wasn''t with
the move of
>  the svn repository outside rubyforge. We could better use gitorius [1]
>  instead of a closed source implementation, like if we go for LaunchPad
>  instead.
>
A lot of projects do primary souce control on Git, but merge to SVN on
rubyforge on a regular basis.  We could do the same, or the reverse.
Maybe we could keep SVN as the primary, but sync it up to Git.
Rubyforge also allows for a Git repo, although I don''t know if it
would be worth changing to it at this point.  Also, I don''t think we
can fault GitHub for being closed source.  After all, we''re all here
because we want Ruby to work as well as possible on a closed source
OS.  GitHub is friendly _and free_ to open source projects, and I
agree with Gerardo that it could help us get more attention.
>  Even we have a full repo that can be relocated/pushed to another
>  hosting/site. I found quite annoying the relocation of repositories of
>  OSS projects.
>
>
>  >  AFAIK, there''s a Git version for MSYS. According to my
logic book,
>  >  since installer3 will run on MSYS, it doesn''t feel wrong to
use
>  >  msysgit, which is already used in production environments (according
>  >  to its Wikipedia entry).
>  >
>
>  Well, I mention msysGit in the original mail, basically it works,
>  still it misses a few bits but works. Still, we should keep using the
>  SVN repo at least for users already using Subversion at their
>  companies or working with other open-source projects that want to
>  contribute back, at least with patches.
I like this idea, there is no reason we can''t do both.

That''s my two cents.

Thanks,

Gordon

On Wed, Apr 23, 2008 at 2:49 PM, Gordon Thiesfeld <gthiesfeld at
gmail.com> wrote:
> On Wed, Apr 23, 2008 at 11:10 AM, Luis Lavena <luislavena at
gmail.com> wrote:
>  >
>  >  I''m not 100% positive abut github. Like Zed wasn''t
with the move of
>  >  the svn repository outside rubyforge. We could better use gitorius
[1]
>  >  instead of a closed source implementation, like if we go for
LaunchPad
>  >  instead.
>  >
>
>  A lot of projects do primary souce control on Git, but merge to SVN on
>  rubyforge on a regular basis.  We could do the same, or the reverse.
>  Maybe we could keep SVN as the primary, but sync it up to Git.
>  Rubyforge also allows for a Git repo, although I don''t know if it
>  would be worth changing to it at this point.  Also, I don''t think
we
>  can fault GitHub for being closed source.  After all, we''re all
here
>  because we want Ruby to work as well as possible on a closed source
>  OS.  GitHub is friendly _and free_ to open source projects, and I
>  agree with Gerardo that it could help us get more attention.
>
>
I think I missed the point about Zed''s comments. The issue with the
svn repo is the "ownership" of it, the viability of the system
you''re
depending on.

DVCS break that model into pieces, all the users contributing to a
project have copies _almost_ up-to date, so I don''t see issues with
that, Git or Bzr models.
>  >
>  >  Well, I mention msysGit in the original mail, basically it works,
>  >  still it misses a few bits but works. Still, we should keep using
the
>  >  SVN repo at least for users already using Subversion at their
>  >  companies or working with other open-source projects that want to
>  >  contribute back, at least with patches.
>
>  I like this idea, there is no reason we can''t do both.
>
I''ll check if latest msysGit support dcommit to push changes back into
SVN, after all, we will only maintain a mirror branch over there.
>  That''s my two cents.
Why only two cents? we all demand more! ;-)
>  Thanks,
>
So basically:

- GitHub rubyinstaller project that holds the new code we have been creating.
- Push via dcommit the changes back into SVN repo [1] as installer3 branch.
- Provide simple instructions in the docs and rake helpers into the
recipes for managing the git repo.

We all agree?

[1] http://rubyinstaller.rubyforge.org/svn

-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

On 23/04/2008, Will Green <will at hotgazpacho.org>
wrote:
> SVN has the lowest barrier to entry for Win32 developers
(Collabnet''s
>  SVN installer for Windows, TortoiseSVN).
>
>  To the best of knowledge, all the other tools (bzr, git, etc) do not
>  have a stable, native win32 client. That is, they all require an
>  existing Cygwin or MinGW install.
>
>  The other benefit of SVN is that if folks want to use git, git-svn can
>  push their changes back to the SVN repo.
>
>  Given that this is a Win32 project for Win32 developers, my vote is for
SVN.
>
I also find SVN or CVS a tool more accessible than git, at least on Windows.

Still I can live with snapshot zips (or tarballs) exported from anything.
Zip archives are probably the most acceptable option for Windows
users, the OS has built-in support for them.

Thanks

Michal