Vadim has been running his own mirror of the wxWidgets C++ source code
here on Gitorious for a long time now:
http://gitorious.org/wxwidgets
- SVN metadata attached
- Does not contain git-svn remote refs (can't use this repo with
git-svn dcommit for those of us with SVN commit access).
- User information mapping included
- Updated only periodically (about every 1-2 months)
- Only contains master (SVN trunk) branch
- No tags
I've personally taken the initiative to setup a (hopefully) more
useful mirror including repos for wxWidgets, wxPython, and their
respective website sources too on GitHub:
https://github.com/wxWidgets
Some details about these repositories:
- SVN metadata attached
- Contains git-svn remote refs (see the wiki pages on each repo for
instructions on how to set this up correctly so you can use git-svn
dcommit - i.e. for wxWidgets:
https://github.com/wxWidgets/wxWidgets/wiki ).
- User information mapping included
- Updated every 10 minutes for wxWidgets and wxPython, updated every
hour for the website sources.
- Contains branch refs for all repos.
- Contains tags for wxWidgets, but not wxPython (looks like those will
need to be re-tagged manually).
For both the tags and branches, you will need to explicitly tell git
to fetch the remote refs from the GitHub repos (if you use the wiki
instructions, this will work).
In the future, these GitHub repos could possibly be used as the main
repos if we do switch to git down the road. I just wanted to get these
mirrors up and encourage wxWidgets developers to experiment with them.
Hopefully this is some encouragement to familiarize yourself with git
version control if you haven't made your way over yet.
Please note that there is another Gitorious mirror of the wxWidgets
SVN code, however, it is no longer maintained (and never did proper
user mapping or sync of any branches anyway) which is found here:
http://gitorious.org/wxwidgets_ - DO NOT USE THIS REPO
Regards,
Bryan Petty
I've recently done the same for Gnucash, and several of the main devs are now using it instead of subversion. I wrote some perl scripts [1] to make keeping git and svn in sync easier; instructions for setup and use are at [2].
Regards,
John Ralls
[1] https://github.com/Gnucash/git-helper-scripts
[2] http://wiki.gnucash.org/wiki/Git
BP> As I would eventually like to see wxWidgets migrate to Git for version
BP> control (this isn't a request to do so at this moment, maybe in a year
BP> or so),
I'm not optimistic about this happening officially any time soon as we
have quite a few committers and persuading all of them to learn git is not
going to be easy. And in the meanwhile all those who did learn it can use
it just fine anyhow.
BP> I've put together my own automatically updated GitHub mirror
BP> of the wxWidgets SVN repo, and also want to outline some of the other
BP> Git mirrors of wxWidgets source available as well.
BP>
BP> Vadim has been running his own mirror of the wxWidgets C++ source code
BP> here on Gitorious for a long time now:
BP> http://gitorious.org/wxwidgets
BP> - SVN metadata attached
I don't think we can get rid of it as long as we want to keep the
possibility to use it in parallelled with svn. I dislike the "git-svn-id:"
lines as well and even asked git-svn developer if it was possible to avoid
them but unfortunately the answer was no.
BP> - Does not contain git-svn remote refs (can't use this repo with
BP> git-svn dcommit for those of us with SVN commit access).
I'm not sure how to set this up to be honest. Wouldn't just adding
[svn-remote "svn"]
url = https://svn.wxwidgets.org/svn/wx
fetch = wxWidgets/trunk:refs/remotes/trunk
branches = wxWidgets/branches/*:refs/remotes/*
tags = wxWidgets/tags/*:refs/remotes/tags/*
to your .git/config be enough to fix this?
BP> - User information mapping included
FWIW it took me quite some time to gather all this information. And there
are still a few people I couldn't find (AN, BV, CR, DM, HB, HH, HK, MO, MT,
NI, PA, RO, RS, UG). Strangely enough there are quite a few differences
between my file and http://cloud.github.com/downloads/wxWidgets/wxWidgets/authors.txt
BP> - Updated only periodically (about every 1-2 months)
It's trivial to set up a cron job to do it... I just never bothered to do
it thinking that maybe we could setup something better, e.g. a full mirror
on the svn server itself maybe. And it looks like you finally did it :-)
BP> - No tags
I don't know why I don't have them to be honest. I just did a simple "git
svn clone -s" AFAIR.
BP> I've personally taken the initiative to setup a (hopefully) more
BP> useful mirror including repos for wxWidgets, wxPython, and their
BP> respective website sources too on GitHub:
BP> https://github.com/wxWidgets
This looks very good, thanks! I think it should be advertised as our
official git mirror to avoid any confusion.
Thanks for doing this!
VZ
> I'm not optimistic about this happening officially any time soon as we
> have quite a few committers and persuading all of them to learn git is not
> going to be easy. And in the meanwhile all those who did learn it can use
> it just fine anyhow.
I'm using svn but am not a committer. But I can definitely see advantages
to git, after watching Linus' talk at Google:
<http://www.youtube.com/watch?v=4XpnKHJAok8>
I'm not optimistic about this happening soon either, but I am hoping
that this is a step in the right direction. Quite honestly, while I
knew that I would eventually need to learn git and migrate over to it,
I barely learned anything about git with my own small hobby projects
(when there's only one developer, and really no branches to manage),
and didn't care until a new, bigger project I became involved in
decided that as a new project, we should start out on git immediately.
That's the only way I managed to finally understand branch management
in git and how rebasing works (and when to use it).
If we put forth the effort to encourage our existing developers to
learn git even if we still aren't officially using it, it puts us a
lot closer to the goal of eventually switching. Certainly some
migration plan would need to be worked out where the developers with
the most experience with git can safely be given write access to the
main git repo to handle pull requests or apply patches from Trac
without the worry of accidentally rebasing some large tree of public
commits, and everyone else either continues to submit patches through
Trac, or submits pull requests through GitHub or something. Anyway,
this is a long ways down the road still.
> BP> - Does not contain git-svn remote refs (can't use this repo with
> BP> git-svn dcommit for those of us with SVN commit access).
>
> I'm not sure how to set this up to be honest. Wouldn't just adding
>
> [svn-remote "svn"]
> url = https://svn.wxwidgets.org/svn/wx
> fetch = wxWidgets/trunk:refs/remotes/trunk
> branches = wxWidgets/branches/*:refs/remotes/*
> tags = wxWidgets/tags/*:refs/remotes/tags/*
>
> to your .git/config be enough to fix this?
This doesn't appear to work with your repo, or mine. git-svn seems to
be confused and just hangs on a rebase.
I used the approach recommended in the git-svn manpage. There is an
additional step you need to do though in order to push a repo like
this up to Gitorious or GitHub though. It's easiest if you just
specify --mirror when adding Gitorious or GitHub as a remote. The
config options you need on the remote though are "fetch =
+refs/*:refs/*" and "mirror = true", and then it's as simple as "git
svn rebase; git push github" (no need to specify refs).
> BP> - User information mapping included
>
> FWIW it took me quite some time to gather all this information. And there
> are still a few people I couldn't find (AN, BV, CR, DM, HB, HH, HK, MO, MT,
> NI, PA, RO, RS, UG). Strangely enough there are quite a few differences
> between my file and http://cloud.github.com/downloads/wxWidgets/wxWidgets/authors.txt
I would be interested in comparing the differences and fixing any
mistakes. I spent a ton of time building that authors file as well,
and had Robin look over it too to hopefully catch any mistakes. I
wouldn't be surprised to see some differences in email addresses used.
I tried to use the author's email address most closely related to
wxWidgets work if I could find it (assuming it wasn't listed on
Robin's SVN authors page), but fell back on whatever email address for
the author I could find on the internet. If we have differences in
actual authors being mapped to different user IDs, I would definitely
like to clear that up.
Could you send the file to me?
> BP> - No tags
>
> I don't know why I don't have them to be honest. I just did a simple "git
> svn clone -s" AFAIR.
This is related to what I explained above with --mirror. Your local
git repo probably does have the branches and tags if you used "git svn
clone -s", but as git-svn stores those as remote refs in your local
repo, they aren't pushed to remote repos by default, and they aren't
copied by git clone either (hence the somewhat lengthy process I've
outlined on that wiki page to clone the GitHub repos). If you add
"fetch = +refs/*:refs/*" and "mirror = true" to your Gitorious remote
in your local repo, and run another push, it will push up your svn
remote refs, allowing others like myself to actually use your
Gitorious repo as a jumping off point for git-svn (if we pull down
your Gitorious repo's remote refs and use the same "git svn init"
parameters you used).
> BP> I've personally taken the initiative to setup a (hopefully) more
> BP> useful mirror including repos for wxWidgets, wxPython, and their
> BP> respective website sources too on GitHub:
> BP> https://github.com/wxWidgets
>
> This looks very good, thanks! I think it should be advertised as our
> official git mirror to avoid any confusion.
Certainly. I've added you as an owner on the wxWidgets organization so
you can handle any changes needed if I'm not around for whatever
reason. Also, ignore the disk space quota in the organization
settings, GitHub has said we're perfectly fine as long as we don't go
over 1GB on any single repo (I already cleared this with them).
Regards,
Bryan Petty
BP> > BP> - User information mapping included
BP> >
BP> > FWIW it took me quite some time to gather all this information. And there
BP> > are still a few people I couldn't find (AN, BV, CR, DM, HB, HH, HK, MO, MT,
BP> > NI, PA, RO, RS, UG). Strangely enough there are quite a few differences
BP> > between my file and http://cloud.github.com/downloads/wxWidgets/wxWidgets/authors.txt
BP>
BP> I would be interested in comparing the differences and fixing any
BP> mistakes.
The mistakes are probably mostly on my end but maybe it still can be
useful, please find my file attached. Notice that you should pipe it
through "sed s/unknown@email/nobody@localhost/" before comparing it with
your version.
BP> > I don't know why I don't have them to be honest. I just did a simple "git
BP> > svn clone -s" AFAIR.
BP>
BP> This is related to what I explained above with --mirror. Your local
BP> git repo probably does have the branches and tags if you used "git svn
BP> clone -s",
Actually I take my words back, I think I didn't use "-s" and cloned only
trunk to save space. I don't remember what did I do exactly and
unfortunately didn't write it down (it started as an experiment before I
really started using git and I didn't think I'd use it initially).
BP> but as git-svn stores those as remote refs in your local
BP> repo, they aren't pushed to remote repos by default, and they aren't
BP> copied by git clone either (hence the somewhat lengthy process I've
BP> outlined on that wiki page to clone the GitHub repos). If you add
BP> "fetch = +refs/*:refs/*" and "mirror = true" to your Gitorious remote
BP> in your local repo, and run another push, it will push up your svn
BP> remote refs, allowing others like myself to actually use your
BP> Gitorious repo as a jumping off point for git-svn (if we pull down
BP> your Gitorious repo's remote refs and use the same "git svn init"
BP> parameters you used).
Anyhow, thanks a lot for the instructions, they definitely are (and will
be) useful.
BP> Certainly. I've added you as an owner on the wxWidgets organization so
BP> you can handle any changes needed if I'm not around for whatever
BP> reason. Also, ignore the disk space quota in the organization
BP> settings, GitHub has said we're perfectly fine as long as we don't go
BP> over 1GB on any single repo (I already cleared this with them).
Thanks for both!
VZ
On 22.05.2011 13:19, Vadim Zeitlin wrote:
> On Fri, 20 May 2011 19:30:56 -0600 Bryan Petty<br...@ibaku.net> wrote:
>
> BP> As I would eventually like to see wxWidgets migrate to Git for version
> BP> control (this isn't a request to do so at this moment, maybe in a year
> BP> or so),
>
> I'm not optimistic about this happening officially any time soon as we
> have quite a few committers and persuading all of them to learn git is not
> going to be easy. And in the meanwhile all those who did learn it can use
> it just fine anyhow.
Just a question, being curious:
Why is the trend (specifically for wx) going towards git?
Why not Mercurial instead?
(I've spent some time looking at both, trying to figure out the pro's and con's of each, and while
I've not yet come to an "final" conclusion, it seems as if git is faster and more flexible
(flexibility that is rarely if ever needed?), but Mercurial is more "compact", i.e. easier to learn
and use.)
And some info that I just found a few minutes ago (in German):
http://www.heise.de/developer/meldung/Transparenter-Abgleich-zwischen-Subversion-und-Git-1246894.html
this text (is probably based on and) links to:
http://subgit.com/
Best regards,
Carsten
--
Cafu - the open-source Game and Graphics Engine
for multiplayer, cross-platform, real-time 3D Action
Learn more at http://www.cafu.de
CF> Just a question, being curious:
CF> Why is the trend (specifically for wx) going towards git?
CF> Why not Mercurial instead?
FWIW I started using hg myself because it looked very similar to git but
simpler and this appealed to me. And I loved hg a lot, it really was great
compared to svn or cvs. But after being forced to use git to work on
another project I simply couldn't go back to hg any more. Whatever it did,
git did better and faster and git branches turned out to be so much more
convenient than hg ones. Of course, my personal experience is not a great
argument but I know several other people who started to use git and could
never go back to something else, even if they already used hg or bzr before
(of course, they wanted to go back even less if they only used svn) and I
don't know anybody who used to use git and switched to hg.
So for me the question now is why would you use hg instead of git which
has become a de facto standard DVCS for open source development? As much as
I like hg (and people behind it seem very nice) I just don't see any reason
to prefer it. And the same is true for bzr which, while much nicer than svn
as well, is still not as great as git (bzr is also tightly coupled to a
single company which I personally don't really like).
CF> (I've spent some time looking at both, trying to figure out the pro's
CF> and con's of each, and while I've not yet come to an "final"
CF> conclusion, it seems as if git is faster and more flexible (flexibility
CF> that is rarely if ever needed?)
Maybe but when you do need it, it's really great to have it at your
fingertips. And I'm not so sure about "rarely": "git rebase -i" probably
qualifies as "extra flexibility" but I use it all the time. Now maybe it's
my own fault for being sloppy but using git is liberating like this: you
can be sloppy temporarily as you can always *easily* change whatever you
did later.
Anyhow, I don't want to start a DVCS flame war^W^W comparison thread. Both
hg and git (and to lesser extent bzr) are great. But git is the most widely
used one and so is for me the natural choice independently of one's
personal preferences.
Regards,
VZ
This is my thoughts exactly. In this case, it's really little to do
with the differences between the DVCSs, they are all really great for
the most part (well, lesser so for bzr, heh). Any one of them would do
great functionality-wise, but git is the one that ended up taking off
and is now the most widely used. So at least with git, we have a the
widest reach of developers already familiar with the system.
At the last Google Summer of Code mentor's summit back in October (and
the year before actually), between all of the open source
organizations represented, nobody ever bothered even mentioning
Mercurial or Bazaar. There were, however, multiple breakout sessions
on how to get everyone's organizations switched over to git (half of
them already claiming that they either have solid plans in place to do
the migration to git, or were already switched over). It really has
just become the standard adopted by open source organizations.
Regards,
Bryan Petty
thank you very much for your replies!
It's good to understand why wx is preparing or planning to switch to git and not another DVCS, even
though I find hg very appealing for the same reasons as you (Vadim) do or did.
And your replies are also very helpful for orientation as I continue along the road to further
familiarize myself with them and eventually pick one of them for my own projects.
So many thanks and best regards,
On Sun, 22 May 2011 13:19:41 +0200, Vadim Zeitlin wrote:
> And there are still a few people I couldn't find (AN, BV, CR, DM, HB,
> HH, HK, MO, MT, NI, PA, RO, RS, UG).
a year or two ago I dug through diverse sources to gather the mapping;
the following additional entries just might be correct:
HH = Harco de Hilster
PA = Patrick Albert
(I didn't find any e-mail address, though)
Cheers
Anders
This looks very likely. His email is also (or was) likely <har...@caos.kun.nl>.
> PA = Patrick Albert
This is also probably correct, and email address was likely
<a...@barjov.frmug.fr.net>. PA commits are mostly MSW-related, and a
version of the old wx manual lists Patrick Albert as working on
"general enhancements" including "WIN32 support" [1].
The same page also lists Harco de Hilster working on CURSES-related
stuff, which seems to tie in well with the numerous hits for Harco de
Hilster working on various Tcl-related projects.
[1] http://cs.oberlin.edu/software/newwxwin/wxhtml/wx/manual/wx19.html
Regards,
Bryan Petty