On 06/12/12 12:44, Vadim Zeitlin wrote:
> On Thu, 06 Dec 2012 07:23:58 +0000 William S Fulton <wsf@...> wrote:
> WSF> I've been happily using git and git-svn for SWIG development recently.
> WSF> Moving our source code control to git has been mentioned previously and
> WSF> I'm at least ready to make the transition if everyone else is. It
> WSF> certainly seems to be a big improvement over svn in a number of areas
> WSF> especially branching and patch management. Are there any objections to
> WSF> moving over and is anyone with some github experience able to help out?
> Obviously no objections from me (I won't crow over about how I told you so
> and all that, even though it's going to be difficult ;-).
Haha, but you are absolutely right!
> WSF> Sourceforge have git hosting
> WSF> http://sourceforge.net/apps/trac/sourceforge/wiki/Git and we could use
> WSF> that, but I get the impression Github is the place where it is all
> WSF> happening. Does anyone have any thoughts/experience they could share?
> Github pull requests feature is very useful for occasional contributors.
> Granted, I don't know if it's going to be used that much with SWIG which is
> a bit difficult to contribute to occasionally, but it wouldn't hurt and
> could encourage people to submit patches for things like documentation, for
Actually the workflow for distributed systems is still a bit foreign to
me. I can understand pull requests for occasional contributors, but
don't really understand what happens for regular contributors. Do the
regular contributors all get write access to master, or are there some
other workflow patterns that we can consider?
> Many people also like the simple Github issues system. Personally I prefer
> something more full-featured but I definitely think that anything,
> including Github, is better than SF tickets.
> Other than that, I do think that Github is the first place where you'd
> look for any project nowadays, especially for non-C/C++ projects: the
> impression I have is that some of the latter still are hosted on SF or
> Google Code but almost everything written in Perl/Python/Ruby/... is on
> WSF> One thing that I was wondering about is linking bug tracking and commits
> WSF> and how to handle the SF bugs.
> To be able to link them you need to use Github issues systems. Here is a
> program doing this: https://github.com/ttencate/sf2github but I haven't
> tested it myself (all I can say is that our import of ~5000 tickets from SF
> to Trac went well when we did it several years ago, but, of course, we
> didn't use this tool).
That program might be useful, thanks.
> WSF> If we go ahead, what should we import into git? I quite like the idea of
> WSF> replicating the full svn repository including branches, which
> WSF> incidentally contains the older cvs history. I don't see any downside to
> WSF> importing it all - Unlike svn, I don't think git gets slower with a
> WSF> larger code history.
> Well, there is a minor drawback of increasing the size of each checkout,
> but I still think we should import the complete history, it could be
> important to not lose anything.
Okay, good, we'll grab all the history.
> WSF> There are some github mirrors and copies of SWIG, eg
> WSF> https://github.com/klickverbot/swig. What is the best way to handle
> WSF> these or work with them? Vadim has put a placeholder in for SWIG at
> WSF> https://github.com/swig, I presume we should use this?
> Yes, this is exactly what it was meant for. I've just added you to the
> "owners team" for this organization so normally you should have full access
> to everything now.
> I do already have a git-svn clone with all the branches
> locally too, so I could push it out there whenever you want.
And that is the one with all the email addresses associated with SF
users when you ported it over? If this git-svn clone is up to date with
all the branches in svn, then you've done a lot of the hard work, so we
definitely could use that. I suppose it has additional branches in it too?
I'd like to release 2.0.9 in a few days and then switch to github. Are
you around this month to help?
Not many folk look at or use the www area in the svn repository -
https://swig.svn.sourceforge.net/svnroot/swig/www, but it basically
contains the website and is updated with the latest docs on each
release. Suggestions for this... put it into a separate git repo?