[Twisted-Python] Twisted Project Jobs Volunteer
Hi, I have been using Twisted for about 6 months and looking for ways in which I could help the project. I just read the announcement and I would like to volunteer for one of the Twisted jobs. I am familiar with bzr and git and for the beginning I would like to start with maintaining the version control mirrors (bzr and git) and if this will not consume all my free time, I would also like to take care of buildbot master and slaves (or some other job that you consider is more important). Beside the job description, I was thinking that creating repositories mirrors on Github/Gitorious could be useful. The Launchpad BZR mirror seems to be functional. Hoping that I can be useful, please let know if my application is accepted. Cheers, -- Adi Roiban
Hey, Cool, thanks for offering to chip in! I think buildbot management is more important, since I can manage github + wolfwood git mirrors pretty much on my own, and the launchpad mirror looks permanently up to snuff. cheers lvh
On 05:56 pm, _@lvh.cc wrote:
Hey,
Cool, thanks for offering to chip in!
I think buildbot management is more important, since I can manage github + wolfwood git mirrors pretty much on my own, and the launchpad mirror looks permanently up to snuff.
*Keeping* the Launchpad bzr mirror up to date is still a job we're trying to assign (that's why it's on the jobs page). Beyond that, it would be nice if more than just trunk were on Launchpad. As it is now, if you want to use Launchpad, you can't work on any branches people have made in svn. Jean-Paul
Hi, To move things forwards, I would like to discuss the next actions for BZR mirror. After the BZR mirror is done, I will look at git. Launchpad BZR mirror ---------------- AFAIK Launchpad can only import a single svn branch, so importing all twisted in-development branches in Launchpad is not possible. Right now, Twisted trunk is mirrored into Launchpad using the bzr mirror and the last change is : 15922. By exarkun on 2011-06-14. Maybe Launchpad can be configured to mirror the SVN trunk branch, instead of the BZR branch. In this way Launchpad mirror will not depend on Twisted BZR mirror errors. Jonathan Lange, do you think this is a good idea? Twisted self hosted BZR mirror ------------------------------ In the following days I will look at the current state of BZR mirror available here http://svn.twistedmatrix.com/bzr/Twisted/ , document the tools used for maintaining the mirror and try to reproduce a mirror on my server. Cheers, Adi On Tue, 2011-07-05 at 19:22 +0000, exarkun@twistedmatrix.com wrote:
On 05:56 pm, _@lvh.cc wrote:
Hey,
Cool, thanks for offering to chip in!
I think buildbot management is more important, since I can manage github + wolfwood git mirrors pretty much on my own, and the launchpad mirror looks permanently up to snuff.
*Keeping* the Launchpad bzr mirror up to date is still a job we're trying to assign (that's why it's on the jobs page).
Beyond that, it would be nice if more than just trunk were on Launchpad. As it is now, if you want to use Launchpad, you can't work on any branches people have made in svn.
Jean-Paul
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Hi, LP BZR Mirror status -------------------- Martin Pool enabled trunk import directly from SVN repo and the branch is available here: https://code.launchpad.net/~vcs-imports/twisted/trunk The mirror is refreshed about every 5 to 6 hours. Only trunk is available. Own BZR Mirror -------------- I have hacked a quick and dirty script for pulling / creating / deleting all Twisted svn branches. The code is here: http://pastebin.ubuntu.com/639582/ Synchronizing all branches takes about 41 minutes on an Intel Xeon 2.8G CPU. It does not uses to much memory since each branch is pulled using a different bzr pull process. Pulling a single branch takes about 15 seconds, so maybe we the SVN repo can have some commit hooks to execute 'bzr pull' in the right branch. ----- Please let me know what do you think should be the next action for resolving the bzr mirror issues? ----- Cheers, Adi On Wed, 2011-07-06 at 22:51 +0300, Adi Roiban wrote:
Hi,
To move things forwards, I would like to discuss the next actions for BZR mirror. After the BZR mirror is done, I will look at git.
Launchpad BZR mirror ----------------
AFAIK Launchpad can only import a single svn branch, so importing all twisted in-development branches in Launchpad is not possible.
Right now, Twisted trunk is mirrored into Launchpad using the bzr mirror and the last change is : 15922. By exarkun on 2011-06-14.
Maybe Launchpad can be configured to mirror the SVN trunk branch, instead of the BZR branch. In this way Launchpad mirror will not depend on Twisted BZR mirror errors.
Jonathan Lange, do you think this is a good idea?
Twisted self hosted BZR mirror ------------------------------
In the following days I will look at the current state of BZR mirror available here http://svn.twistedmatrix.com/bzr/Twisted/ , document the tools used for maintaining the mirror and try to reproduce a mirror on my server.
Cheers, Adi
On Tue, 2011-07-05 at 19:22 +0000, exarkun@twistedmatrix.com wrote:
On 05:56 pm, _@lvh.cc wrote:
Hey,
Cool, thanks for offering to chip in!
I think buildbot management is more important, since I can manage github + wolfwood git mirrors pretty much on my own, and the launchpad mirror looks permanently up to snuff.
*Keeping* the Launchpad bzr mirror up to date is still a job we're trying to assign (that's why it's on the jobs page).
Beyond that, it would be nice if more than just trunk were on Launchpad. As it is now, if you want to use Launchpad, you can't work on any branches people have made in svn.
Jean-Paul
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
On 7 Jul, 04:25 pm, adi@roiban.ro wrote:
Hi,
LP BZR Mirror status --------------------
Martin Pool enabled trunk import directly from SVN repo and the branch is available here: https://code.launchpad.net/~vcs-imports/twisted/trunk
The mirror is refreshed about every 5 to 6 hours. Only trunk is available.
Cool.
Own BZR Mirror --------------
I have hacked a quick and dirty script for pulling / creating / deleting all Twisted svn branches.
The code is here: http://pastebin.ubuntu.com/639582/
Synchronizing all branches takes about 41 minutes on an Intel Xeon 2.8G CPU. It does not uses to much memory since each branch is pulled using a different bzr pull process.
Pulling a single branch takes about 15 seconds, so maybe we the SVN repo can have some commit hooks to execute 'bzr pull' in the right branch.
I think getting the right hook set up to update just the right branch is what we want to focus on. Presently svn and bzr are hosted on the same machine, which perhaps we can continue since this should bring the overhead of mirroring down. There is even a little code in lp:twisted- trac-integration for determining which branch a changeset is on (at least for the branch creation changeset) which might help.
Please let me know what do you think should be the next action for resolving the bzr mirror issues?
Do you think you can put together something to run from an svn post- commit hook to update just the single corresponding bzr branch? Meanwhile I can try your synchronization code to see if it has better results than the current bzr svn-import based approach. Thanks, Jean-Paul
On Fri, 2011-07-08 at 16:20 +0000, exarkun@twistedmatrix.com wrote:
On 7 Jul, 04:25 pm, adi@roiban.ro wrote: [snip]
Pulling a single branch takes about 15 seconds, so maybe we the SVN repo can have some commit hooks to execute 'bzr pull' in the right branch.
I think getting the right hook set up to update just the right branch is what we want to focus on. Presently svn and bzr are hosted on the same machine, which perhaps we can continue since this should bring the overhead of mirroring down. There is even a little code in lp:twisted- trac-integration for determining which branch a changeset is on (at least for the branch creation changeset) which might help.
Please let me know what do you think should be the next action for resolving the bzr mirror issues?
Do you think you can put together something to run from an svn post- commit hook to update just the single corresponding bzr branch?
Yes. I will write the svn hooks for creating, updating and deleting the mirrored branches.
Meanwhile I can try your synchronization code to see if it has better results than the current bzr svn-import based approach.
You can also try to run a 5 minutes cron job for pulling just the trunk, and another job for pulling each branch. -- Adi
On 9 Jul, 10:46 am, adi@roiban.ro wrote:
On Fri, 2011-07-08 at 16:20 +0000, exarkun@twistedmatrix.com wrote:
On 7 Jul, 04:25 pm, adi@roiban.ro wrote: [snip]
Pulling a single branch takes about 15 seconds, so maybe we the SVN repo can have some commit hooks to execute 'bzr pull' in the right branch.
I think getting the right hook set up to update just the right branch is what we want to focus on. Presently svn and bzr are hosted on the same machine, which perhaps we can continue since this should bring the overhead of mirroring down. There is even a little code in lp:twisted- trac-integration for determining which branch a changeset is on (at least for the branch creation changeset) which might help.
Please let me know what do you think should be the next action for resolving the bzr mirror issues?
Do you think you can put together something to run from an svn post- commit hook to update just the single corresponding bzr branch?
Yes. I will write the svn hooks for creating, updating and deleting the mirrored branches.
Meanwhile I can try your synchronization code to see if it has better results than the current bzr svn-import based approach.
You can also try to run a 5 minutes cron job for pulling just the trunk, and another job for pulling each branch.
I ran this (all-branches version) a few times over the weekend. The first time, when there was lots of catching up to do, took about 3.5 hours. After that, it was about 30 minutes per run. This does seem fast enough to do nightly, so I'll set that up until we have the push- based version. Thanks, Jean-Paul
On Mon, 2011-07-11 at 11:30 +0000, exarkun@twistedmatrix.com wrote:
On 9 Jul, 10:46 am, adi@roiban.ro wrote:
On Fri, 2011-07-08 at 16:20 +0000, exarkun@twistedmatrix.com wrote:
On 7 Jul, 04:25 pm, adi@roiban.ro wrote: [snip] [snip]
I ran this (all-branches version) a few times over the weekend. The first time, when there was lots of catching up to do, took about 3.5 hours. After that, it was about 30 minutes per run. This does seem fast enough to do nightly, so I'll set that up until we have the push- based version.
I have created a script that can be used together with a svn post-commit hook to keep an bzr mirror in sync. The sample usage in a post-commit hook can be found at the following url. The standard output is redirected into a file, and error messages will be displayed in the client console. http://paste.ubuntu.com/642581/ The actual script is here: http://paste.ubuntu.com/642587/ Let me know if the script is not documented enough and more documentation is required. Cheers, -- Adi
On 12 Jul, 12:11 pm, adi@roiban.ro wrote:
On Mon, 2011-07-11 at 11:30 +0000, exarkun@twistedmatrix.com wrote:
On Fri, 2011-07-08 at 16:20 +0000, exarkun@twistedmatrix.com wrote:
On 7 Jul, 04:25 pm, adi@roiban.ro wrote: [snip] [snip] I ran this (all-branches version) a few times over the weekend. The first time, when there was lots of catching up to do, took about 3.5 hours. After that, it was about 30 minutes per run. This does seem fast enough to do nightly, so I'll set that up until we have the push-
On 9 Jul, 10:46 am, adi@roiban.ro wrote: based version.
I have created a script that can be used together with a svn post- commit hook to keep an bzr mirror in sync.
Thanks. Sorry about the delay in getting back to you on this. Another issue I think the push version needs to deal with is concurrent invocation. It looks like the script will issue overlapping "bzr pull" commands now, which doesn't work very well. Do you think you could add some locking somewhere to avoid this? Thanks again, Jean-Paul
On Mon, 2011-08-08 at 13:07 +0000, exarkun@twistedmatrix.com wrote:
On 12 Jul, 12:11 pm, adi@roiban.ro wrote:
On Mon, 2011-07-11 at 11:30 +0000, exarkun@twistedmatrix.com wrote:
On Fri, 2011-07-08 at 16:20 +0000, exarkun@twistedmatrix.com wrote:
On 7 Jul, 04:25 pm, adi@roiban.ro wrote: [snip] [snip] I ran this (all-branches version) a few times over the weekend. The first time, when there was lots of catching up to do, took about 3.5 hours. After that, it was about 30 minutes per run. This does seem fast enough to do nightly, so I'll set that up until we have the push-
On 9 Jul, 10:46 am, adi@roiban.ro wrote: based version.
I have created a script that can be used together with a svn post- commit hook to keep an bzr mirror in sync.
Thanks. Sorry about the delay in getting back to you on this. Another issue I think the push version needs to deal with is concurrent invocation. It looks like the script will issue overlapping "bzr pull" commands now, which doesn't work very well. Do you think you could add some locking somewhere to avoid this?
Thanks again, Jean-Paul
Hi. Don't worry for the delay. I have added locking to the script. The result is here: https://github.com/adiroiban/scripts/tree/master/svn-bzr-sync-hook Feel free to review the code when you have time and let me know if you find any other problems. -- Adi
On Wed, Jul 6, 2011 at 8:51 PM, Adi Roiban <adi@roiban.ro> wrote:
Hi,
To move things forwards, I would like to discuss the next actions for BZR mirror. After the BZR mirror is done, I will look at git.
Launchpad BZR mirror ----------------
AFAIK Launchpad can only import a single svn branch, so importing all twisted in-development branches in Launchpad is not possible.
Right now, Twisted trunk is mirrored into Launchpad using the bzr mirror and the last change is : 15922. By exarkun on 2011-06-14.
Maybe Launchpad can be configured to mirror the SVN trunk branch, instead of the BZR branch. In this way Launchpad mirror will not depend on Twisted BZR mirror errors.
Jonathan Lange, do you think this is a good idea?
I'm pretty sure that you can mirror arbitrary branches from a Subversion repository. One thing you could do is have a post_commit hook in the Twisted SVN repo that creates import branches on Launchpad when needed and tells Launchpad when branches have changed. Oh, and yes I think it's a good idea. Thanks for volunteering! jml
On 5 Jul, 05:51 pm, adi@roiban.ro wrote:
Hi,
I have been using Twisted for about 6 months and looking for ways in which I could help the project.
I just read the announcement and I would like to volunteer for one of the Twisted jobs.
I am familiar with bzr and git and for the beginning I would like to start with maintaining the version control mirrors (bzr and git) and if this will not consume all my free time, I would also like to take care of buildbot master and slaves (or some other job that you consider is more important).
Beside the job description, I was thinking that creating repositories mirrors on Github/Gitorious could be useful. The Launchpad BZR mirror seems to be functional.
Hoping that I can be useful, please let know if my application is accepted.
Hi Adi, Thanks for volunteering. It seems like the git mirror is well in hand. Perhaps you could take on just the bzr mirror for now. The buildbot related jobs are also still open. :) Send me a private email, or find me on Freenode, and we'll talk more about the details. Thanks! Jean-Paul
On 06/07/11 20:44, exarkun@twistedmatrix.com wrote:
Thanks for volunteering. It seems like the git mirror is well in hand.
If so, can someone update this: http://twistedmatrix.com/trac/wiki/GitMirror
On 7 Jul, 01:28 pm, p.mayers@imperial.ac.uk wrote:
On 06/07/11 20:44, exarkun@twistedmatrix.com wrote:
Thanks for volunteering. It seems like the git mirror is well in hand.
If so, can someone update this:
Apparently not. It seems the other volunteers to deal with the git mirror haven't been able to dedicate the time necessary to this. Anyone new want to step up? Jean-Paul
On Nov 8, 2011, at 5:11 PM, exarkun@twistedmatrix.com wrote:
On 7 Jul, 01:28 pm, p.mayers@imperial.ac.uk wrote:
On 06/07/11 20:44, exarkun@twistedmatrix.com wrote:
Thanks for volunteering. It seems like the git mirror is well in hand.
If so, can someone update this:
Apparently not. It seems the other volunteers to deal with the git mirror haven't been able to dedicate the time necessary to this.
Anyone new want to step up?
I should stress that the most pressing problem here is not necessarily to provide a comprehensive, elaborate, automatic mirroring setup, but rather to provide canonical, correct, convenient instructions to people who are submitting tickets for review, and who want to use git for development. Ideally these instructions would not end up knocking over our version control server, either :). Right now, patches from git users show up in a variety of states of confusion and disarray: they're either based on an incredibly ancient version of trunk, or they're on a non-master branch of some repository and they don't say that, or they include 'a/' and 'b/' prefixes (i.e. they're -p1 patches when they should be -p0 according to the submission standard). This is increasingly frustrating for me as a reviewer. I've got git installed; I don't even mind running a git command or two in the process of doing a review. But I would really like to get our submission standards straight so that the patches and branches that show up for review are something I (and others) can sensibly apply. -glyph
2011/11/8 Glyph Lefkowitz <glyph@twistedmatrix.com>
On Nov 8, 2011, at 5:11 PM, exarkun@twistedmatrix.com wrote:
On 7 Jul, 01:28 pm, p.mayers@imperial.ac.uk wrote:
On 06/07/11 20:44, exarkun@twistedmatrix.com wrote:
Thanks for volunteering. It seems like the git mirror is well in hand.
If so, can someone update this:
Apparently not. It seems the other volunteers to deal with the git mirror haven't been able to dedicate the time necessary to this.
Anyone new want to step up?
I should stress that the most pressing problem here is not necessarily to provide a comprehensive, elaborate, automatic mirroring setup, but rather to provide canonical, correct, convenient instructions to people who are submitting tickets for review, and who want to use git for development. Ideally these instructions would not end up knocking over our version control server, either :). Right now, patches from git users show up in a variety of states of confusion and disarray: they're either based on an incredibly ancient version of trunk, or they're on a non-master branch of some repository and they don't say that, or they include 'a/' and 'b/' prefixes (i.e. they're -p1 patches when they should be -p0 according to the submission standard).
This is increasingly frustrating for me as a reviewer. I've got git installed; I don't even mind running a git command or two in the process of doing a review. But I would really like to get our submission standards straight so that the patches and branches that show up for review are something I (and others) can sensibly apply.
I am about to go out of town, but when I get back (December) I will have a go at this if no one else has done so already. Every time in the past when I have attempted to make a git clone of the Twisted repository, git has complained that the Twisted svn repo is corrupt in some way. If there is already a reliable bzr mirror of Twisted, it might be easier to base the git repo on that instead. Does that seem feasible? dave
On Nov 8, 2011, at 6:30 PM, Dave Peticolas wrote:
I am about to go out of town, but when I get back (December) I will have a go at this if no one else has done so already.
Great, glad to hear it. I hope we won't have to wait that long though ;).
Every time in the past when I have attempted to make a git clone of the Twisted repository, git has complained that the Twisted svn repo is corrupt in some way.
It's a good thing that git has such lucid, well-documented error messages, or that message might confuse some people. *cough*
If there is already a reliable bzr mirror of Twisted, it might be easier to base the git repo on that instead. Does that seem feasible?
The reliable bzr mirror is available at <http://svn.twistedmatrix.com/bzr/Twisted/>. I don't know much about bzr / git conversion beyond the existence of <https://launchpad.net/bzr-git>. Does it work? Is it any good? The fact that it says right in the description that it doesn't support 'push' suggests to me that you can't get revisions from bzr to git, but hopefully I'm wrong about that. -glyph
On Tue, Nov 08, 2011 at 05:43:09PM -0800, Glyph Lefkowitz wrote:
On 7 Jul, 01:28 pm, p.mayers@imperial.ac.uk wrote:
I should stress that the most pressing problem here is not necessarily to provide a comprehensive, elaborate, automatic mirroring setup, but rather to provide canonical, correct, convenient instructions to people who are submitting tickets for review, and who want to use git for development. Ideally these instructions would not end up knocking over our version control server, either :).
As far as I know (having written most of the documentation in the linked wiki page, and from a brief skim through the git-svn manpage) it's impossible to make a "shallow" clone with git-svn (something like an ordinary "svn checkout", or "git clone --depth N"), so anyone who wants to contribute to Twisted via git needs to clone the repository from scratch (potentially overloading the SVN server, although nobody seemed to notice or complain when I was doing my git-svn clone), or just copy a tarball of somebody's comprehensive, elaborate, automatic mirroring setup. I'm not sure why I didn't document how to properly clone the Twisted SVN repo with git-svn; I don't recall it being too hard (with the exception of some old, closed branches with '+' in the name which I just blew away), but it did take long enough that I didn't really want to experiment and risk overloading the SVN server. With access to the SVN server over a local network, or with a lot of patience, it shouldn't take much messing about to figure out canonical "make a clone" and "update your clone" instructions.
Right now, patches from git users show up in a variety of states of confusion and disarray: they're either based on an incredibly ancient version of trunk, or they're on a non-master branch of some repository and they don't say that,
I'm not sure why that would be, except that possibly they found a tarball of somebody else's git-svn clone and forgot to update it, or they're confused about the best way to get cloned from some unofficial, no-longer updated mirror. Fixing this probably depends on having the canonical, correct, convenient instructions and advertising them widely.
or they include 'a/' and 'b/' prefixes (i.e. they're -p1 patches when they should be -p0 according to the submission standard).
Git doesn't provide any way to generate patches without the fixed, standard prefixes. As I understand it, this is to prevent ambiguities when filenames contain spaces. So, you're probably stuck with it. :/
On Wed, Nov 9, 2011 at 03:39, Tim Allen <screwtape@froup.com> wrote:
On Tue, Nov 08, 2011 at 05:43:09PM -0800, Glyph Lefkowitz wrote:
or they include 'a/' and 'b/' prefixes (i.e. they're -p1 patches when they should be -p0 according to the submission standard).
Git doesn't provide any way to generate patches without the fixed, standard prefixes. As I understand it, this is to prevent ambiguities when filenames contain spaces. So, you're probably stuck with it. :/
I thought so too, but Glyph found this today: git diff --src-prefix="./" --dst-prefix="./" Ivan
On Nov 8, 2011, at 7:39 PM, Tim Allen wrote:
On Tue, Nov 08, 2011 at 05:43:09PM -0800, Glyph Lefkowitz wrote:
On 7 Jul, 01:28 pm, p.mayers@imperial.ac.uk wrote:
I should stress that the most pressing problem here is not necessarily to provide a comprehensive, elaborate, automatic mirroring setup, but rather to provide canonical, correct, convenient instructions to people who are submitting tickets for review, and who want to use git for development. Ideally these instructions would not end up knocking over our version control server, either :).
As far as I know (having written most of the documentation in the linked wiki page, and from a brief skim through the git-svn manpage) it's impossible to make a "shallow" clone with git-svn (something like an ordinary "svn checkout", or "git clone --depth N"), so anyone who wants to contribute to Twisted via git needs to clone the repository from scratch (potentially overloading the SVN server, although nobody seemed to notice or complain when I was doing my git-svn clone), or just copy a tarball of somebody's comprehensive, elaborate, automatic mirroring setup.
This is the part I don't understand. Why doesn't 'git clone' work right in the face of svn metadata? Is it possible to make it work right? bzr-svn has some metadata it caches about the svn repository which doesn't stick around in the bzr repo or branch, but (from the performance of using it, at least) it doesn't need to stop the world and grab all of that data for most operations.
I'm not sure why I didn't document how to properly clone the Twisted SVN repo with git-svn; I don't recall it being too hard (with the exception of some old, closed branches with '+' in the name which I just blew away), but it did take long enough that I didn't really want to experiment and risk overloading the SVN server.
It would be better (for most users) to point to a canonical way to get access to a git-svn clone than to document how to make one, if making one takes 24 hours :). But please do write this down so that at least the Twisted admins have some concept of how to re-create the git mirror or how to fix the issue if it occurs in the future.
With access to the SVN server over a local network, or with a lot of patience, it shouldn't take much messing about to figure out canonical "make a clone" and "update your clone" instructions.
If we had an officially maintained mirror (pushed to github, I hope), I assume that non-committer users would not need to do SVN operations. That's the main audience I'm interested in right now. There are a couple of committers who might be interested in doing development with git, but I'm confident they can figure that out for themselves :).
Right now, patches from git users show up in a variety of states of confusion and disarray: they're either based on an incredibly ancient version of trunk, or they're on a non-master branch of some repository and they don't say that,
I'm not sure why that would be, except that possibly they found a tarball of somebody else's git-svn clone and forgot to update it, or they're confused about the best way to get cloned from some unofficial, no-longer updated mirror. Fixing this probably depends on having the canonical, correct, convenient instructions and advertising them widely.
You edited GitMirror before, you can do it again :).
or they include 'a/' and 'b/' prefixes (i.e. they're -p1 patches when they should be -p0 according to the submission standard).
Git doesn't provide any way to generate patches without the fixed, standard prefixes. As I understand it, this is to prevent ambiguities when filenames contain spaces. So, you're probably stuck with it. :/
I finally figured this out. It is fixable. The correct options to pass are: git diff --src-prefix=./ --dst-prefix=./ Maybe it's possible to put this into a configuration file somewhere so that users don't need to type all of that every time? Please put this on the GitMirror page as well. -glyph
On Wed, Nov 09, 2011 at 12:50:23AM -0800, Glyph Lefkowitz wrote:
On Nov 8, 2011, at 7:39 PM, Tim Allen wrote:
As far as I know (having written most of the documentation in the linked wiki page, and from a brief skim through the git-svn manpage) it's impossible to make a "shallow" clone with git-svn (something like an ordinary "svn checkout", or "git clone --depth N"), so anyone who wants to contribute to Twisted via git needs to clone the repository from scratch (potentially overloading the SVN server, although nobody seemed to notice or complain when I was doing my git-svn clone), or just copy a tarball of somebody's comprehensive, elaborate, automatic mirroring setup.
This is the part I don't understand. Why doesn't 'git clone' work right in the face of svn metadata?
Git has a ".git" directory in each repository, and expects certain files to be present within it. If there's more stuff that it doesn't know about, it just ignores it. git-svn keeps its metadata in other files that git-clone doesn't know or care about, and hence they don't get cloned. I guess there's an argument for not cloning them - just because person X has particular access rights to an SVN server doesn't mean that person Y should have them just because they cloned a repository from X.
bzr-svn has some metadata it caches about the svn repository which doesn't stick around in the bzr repo or branch, but (from the performance of using it, at least) it doesn't need to stop the world and grab all of that data for most operations.
In a git-svn-cloned repository, ordinary git operations are as speedy as you'd expect. "git svn fetch" is slow because (I think) it has to separately request each changed file from each SVN revision, and I think there's some other operations that are slow because they involve talking to the SVN server (like 'tell me what SVN properties are attached to this file').
It would be better (for most users) to point to a canonical way to get access to a git-svn clone than to document how to make one, if making one takes 24 hours :).
Don't worry, it doesn't take 24 hours! It's *much* longer than that! ;) (as the wiki page states, in early 2010 and from the other side of the world it took about a week; I don't have a feel for how it changes over time)
I'm not sure why that would be, except that possibly they found a tarball of somebody else's git-svn clone and forgot to update it, or they're confused about the best way to get cloned from some unofficial, no-longer updated mirror. Fixing this probably depends on having the canonical, correct, convenient instructions and advertising them widely.
You edited GitMirror before, you can do it again :).
I'm editing it to include what we've discussed here, as well as a few other things that I researched this afternoon and put into a reply that my MUA ate before it was sent. I believe the next step should be that somebody with the required permissions should connect to a machine on the same physical network as the SVN server and run: time git svn clone --stdlayout --prefix="svn/" \ svn+ssh://svn.twistedmatrix.com/svn/Twisted ...then check the load on the SVN server and see if it's going to be an issue to let the clone complete. If the clone completes successfully, then (a) we know about how long it takes, and (b) we have a "seed" repository we can potentially put up for people to download. I'd be happy to download it, check it, and write up some documentation about how people should update it. If it doesn't complete successfully, we should have some helpful error messages, adjust the clone command line and try again.
On 12:49 pm, screwtape@froup.com wrote:
[snip]
I believe the next step should be that somebody with the required permissions should connect to a machine on the same physical network as the SVN server and run:
time git svn clone --stdlayout --prefix="svn/" \ svn+ssh://svn.twistedmatrix.com/svn/Twisted
...then check the load on the SVN server and see if it's going to be an issue to let the clone complete. If the clone completes successfully, then (a) we know about how long it takes, and (b) we have a "seed" repository we can potentially put up for people to download. I'd be happy to download it, check it, and write up some documentation about how people should update it. If it doesn't complete successfully, we should have some helpful error messages, adjust the clone command line and try again.
Why do we need to do this again? There's already <http://svn.twistedmatrix.com/git/Twisted>, <http://svn.twistedmatrix.com/git/Twisted2.git>, and <http://svn.twistedmatrix.com/git/Twisted3.git>. Jean-Paul
While we're on the topic of version control, I thought I'd mention that I tried to create a mercurial mirror of the SVN repo using hgsubversion a couple of weeks ago. It ran fine until it eventually hung on a particular commit and just refused to go any further. I had planned to ask the hgsubversion people about this but got distracted by other things. I still intend to follow up at some point. Kevin Horn
On Wed, 9 Nov 2011 07:38:31 -0600 Kevin Horn <kevin.horn@gmail.com> wrote:
While we're on the topic of version control, I thought I'd mention that I tried to create a mercurial mirror of the SVN repo using hgsubversion a couple of weeks ago. It ran fine until it eventually hung on a particular commit and just refused to go any further. I had planned to ask the hgsubversion people about this but got distracted by other things.
I'm not using hgsubversion but I have a simple mirror of SVN trunk (and only that) here: http://hg.pitrou.net/public/twisted/trunk/ Or you can also use https://bitbucket.org/pitrou/t3k/, which implicitly contains the above-mentioned truk. Regards Antoine.
On Wed, Nov 09, 2011 at 01:22:19PM -0000, exarkun@twistedmatrix.com wrote:
Why do we need to do this again? There's already <http://svn.twistedmatrix.com/git/Twisted>, <http://svn.twistedmatrix.com/git/Twisted2.git>, and <http://svn.twistedmatrix.com/git/Twisted3.git>.
The wiki mentions the first one a couple of times, although strictly speaking you need to add "/.git" to the end to get a URL you can clone from. Apart from being out-of-date, it seems to be missing a lot of branches (there's only 56, and it stopped updating in 2011-03; my personal git-svn hasn't been updated since 2010-09 and has 2062 branches), it hasn't correctly imported the branches under "releases", and the only tags are "last_vfs_and_web2" and "releases". I guess it's not strictly necessary to have tags or releases imported if the goal is to let people develop patches against trunk, but the fact that branches are missing worries me - if a Twisted committer adds your patch to a branch, you want to be confident that the new branch will actually show up when you update your repository. As for the other two, this is the first I've heard of them. Is there any documentation about how they differ, are there records of how these repositories were created and/or updated that I could add to the GitMirror wiki-page?
On 02:18 pm, screwtape@froup.com wrote:
On Wed, Nov 09, 2011 at 01:22:19PM -0000, exarkun@twistedmatrix.com wrote:
Why do we need to do this again? There's already <http://svn.twistedmatrix.com/git/Twisted>, <http://svn.twistedmatrix.com/git/Twisted2.git>, and <http://svn.twistedmatrix.com/git/Twisted3.git>.
The wiki mentions the first one a couple of times, although strictly speaking you need to add "/.git" to the end to get a URL you can clone from. Apart from being out-of-date, it seems to be missing a lot of branches (there's only 56, and it stopped updating in 2011-03; my personal git-svn hasn't been updated since 2010-09 and has 2062 branches), it hasn't correctly imported the branches under "releases", and the only tags are "last_vfs_and_web2" and "releases".
It's out of date because no one who knows how to keep it updated has taken the necessary steps for that to happen. Are there other problems with it which can only be fixed by starting over? The point I am trying to convey is that performing some one-off import operation has been done before, repeatedly. What's going to be different this time that causes the clone to stay up to date?
I guess it's not strictly necessary to have tags or releases imported if the goal is to let people develop patches against trunk, but the fact that branches are missing worries me - if a Twisted committer adds your patch to a branch, you want to be confident that the new branch will actually show up when you update your repository.
Indeed. Is this something that's addressed by the git command in your earlier email?
As for the other two, this is the first I've heard of them. Is there any documentation about how they differ, are there records of how these repositories were created and/or updated that I could add to the GitMirror wiki-page?
I have no idea where they came from or how they differ. Jean-Paul
On Wed, Nov 09, 2011 at 02:49:50PM -0000, exarkun@twistedmatrix.com wrote:
On 02:18 pm, screwtape@froup.com wrote:
On Wed, Nov 09, 2011 at 01:22:19PM -0000, exarkun@twistedmatrix.com wrote:
Why do we need to do this again? There's already <http://svn.twistedmatrix.com/git/Twisted>, <http://svn.twistedmatrix.com/git/Twisted2.git>, and <http://svn.twistedmatrix.com/git/Twisted3.git>.
The wiki mentions the first one a couple of times, although strictly speaking you need to add "/.git" to the end to get a URL you can clone from. Apart from being out-of-date, it seems to be missing a lot of branches (there's only 56, and it stopped updating in 2011-03; my personal git-svn hasn't been updated since 2010-09 and has 2062 branches), it hasn't correctly imported the branches under "releases", and the only tags are "last_vfs_and_web2" and "releases".
It's out of date because no one who knows how to keep it updated has taken the necessary steps for that to happen.
Are there other problems with it which can only be fixed by starting over?
I suspect that the other problems I mentioned can only be fixed by starting over, yes.
The point I am trying to convey is that performing some one-off import operation has been done before, repeatedly. What's going to be different this time that causes the clone to stay up to date?
I fully expect that whatever broke previous attempts will break this new attempt too. The difference will be that since there's a record of how the new repository was created, and assuming there'll be a record of what happened when the new repository broke, this time we'll be able to reproduce the problem and work out a solution.
I guess it's not strictly necessary to have tags or releases imported if the goal is to let people develop patches against trunk, but the fact that branches are missing worries me - if a Twisted committer adds your patch to a branch, you want to be confident that the new branch will actually show up when you update your repository.
Indeed. Is this something that's addressed by the git command in your earlier email?
The "--stdlayout" parameter causes git-svn to import branches in the standard SVN "branches" directory, which is where Twisted seems to keep its feature branches (the most important ones for people working on patches). With some effort it might be possible to import release branches in "branches/releases", but that's obviously a lesser priority.
As for the other two, this is the first I've heard of them. Is there any documentation about how they differ, are there records of how these repositories were created and/or updated that I could add to the GitMirror wiki-page?
I have no idea where they came from or how they differ.
It turns out Twisted2 is the newest (July 2011) and has about the right number of branches. It also seems to have imported the various "ctrl+backslash-2371+2123" branches that I recall causing issues before. On the other hand, it still imports "branches/releases" as a single branch, and has no tags. "Twisted3" might have been created for one of those reasons... or possibly for some other reason that's not immediately obvious.
On Wed, Nov 9, 2011 at 7:22 AM, <exarkun@twistedmatrix.com> wrote:
Why do we need to do this again? There's already <http://svn.twistedmatrix.com/git/Twisted>,
Last updated in March 2011.
Last updated in 2004
Last updated in July 2011. They all appear to be flawed in that the tags/releases and branches/releases directories were imported improperly. -- Jeff Ollie
On Nov 9, 2011, at 11:41 AM, Jeffrey Ollie wrote:
On Wed, Nov 9, 2011 at 7:22 AM, <exarkun@twistedmatrix.com> wrote:
Why do we need to do this again? There's already <http://svn.twistedmatrix.com/git/Twisted>,
Last updated in March 2011.
Last updated in 2004
Last updated in July 2011.
They all appear to be flawed in that the tags/releases and branches/releases directories were imported improperly.
The question is: will the suggested re-import actually import those directories properly? The command-line in the previous email doesn't suggest that to me; I would imagine it would at least have to have the word "releases" in there somewhere, since that's not part of the SVN layout. -glyph
On Wed, Nov 9, 2011 at 1:42 PM, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
On Nov 9, 2011, at 11:41 AM, Jeffrey Ollie wrote:
On Wed, Nov 9, 2011 at 7:22 AM, <exarkun@twistedmatrix.com> wrote:
Why do we need to do this again? There's already <http://svn.twistedmatrix.com/git/Twisted>,
Last updated in March 2011.
Last updated in 2004
Last updated in July 2011.
They all appear to be flawed in that the tags/releases and branches/releases directories were imported improperly.
The question is: will the suggested re-import actually import those directories properly? The command-line in the previous email doesn't suggest that to me; I would imagine it would at least have to have the word "releases" in there somewhere, since that's not part of the SVN layout.
No, the suggested re-import won't work - it'll have the same flaws. I'm working on adapting some scripts that I use to maintain my git mirror of the Asterisk SVN repository which has some of the same problems. -- Jeff Ollie
On Nov 9, 2011, at 11:47 AM, Jeffrey Ollie wrote:
On Wed, Nov 9, 2011 at 1:42 PM, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
On Nov 9, 2011, at 11:41 AM, Jeffrey Ollie wrote:
On Wed, Nov 9, 2011 at 7:22 AM, <exarkun@twistedmatrix.com> wrote:
Why do we need to do this again? There's already <http://svn.twistedmatrix.com/git/Twisted>,
Last updated in March 2011.
Last updated in 2004
Last updated in July 2011.
They all appear to be flawed in that the tags/releases and branches/releases directories were imported improperly.
The question is: will the suggested re-import actually import those directories properly? The command-line in the previous email doesn't suggest that to me; I would imagine it would at least have to have the word "releases" in there somewhere, since that's not part of the SVN layout.
No, the suggested re-import won't work - it'll have the same flaws. I'm working on adapting some scripts that I use to maintain my git mirror of the Asterisk SVN repository which has some of the same problems.
Thanks! I look forward to seeing them.
On 11/09/2011 07:49 AM, Tim Allen wrote:
On Wed, Nov 09, 2011 at 12:50:23AM -0800, Glyph Lefkowitz wrote:
On Nov 8, 2011, at 7:39 PM, Tim Allen wrote:
As far as I know (having written most of the documentation in the linked wiki page, and from a brief skim through the git-svn manpage) it's impossible to make a "shallow" clone with git-svn (something like an ordinary "svn checkout", or "git clone --depth N"), so anyone who wants to contribute to Twisted via git needs to clone the repository from scratch (potentially overloading the SVN server, although nobody seemed to notice or complain when I was doing my git-svn clone), or just copy a tarball of somebody's comprehensive, elaborate, automatic mirroring setup.
This is the part I don't understand. Why doesn't 'git clone' work right in the face of svn metadata?
Git has a ".git" directory in each repository, and expects certain files to be present within it. If there's more stuff that it doesn't know about, it just ignores it. git-svn keeps its metadata in other files that git-clone doesn't know or care about, and hence they don't get cloned.
I guess there's an argument for not cloning them - just because person X has particular access rights to an SVN server doesn't mean that person Y should have them just because they cloned a repository from X.
bzr-svn has some metadata it caches about the svn repository which doesn't stick around in the bzr repo or branch, but (from the performance of using it, at least) it doesn't need to stop the world and grab all of that data for most operations.
In a git-svn-cloned repository, ordinary git operations are as speedy as you'd expect. "git svn fetch" is slow because (I think) it has to separately request each changed file from each SVN revision, and I think there's some other operations that are slow because they involve talking to the SVN server (like 'tell me what SVN properties are attached to this file').
It would be better (for most users) to point to a canonical way to get access to a git-svn clone than to document how to make one, if making one takes 24 hours :).
Don't worry, it doesn't take 24 hours! It's *much* longer than that! ;)
(as the wiki page states, in early 2010 and from the other side of the world it took about a week; I don't have a feel for how it changes over time)
It's worth noting that you aren't *required* to clone all eight trillion Twisted revisions in order to get a working clone. Doing `git svn clone -rN:HEAD <url>` where `N` is some revision number will only clone from that revision. Obviously you will not have the entire history of the repository at this point, but I highly doubt that would be a meaningful loss for the majority of use cases. I mean, yeah, it'd be nice to have a full git clone, but if you just prefer to use git for development and want to submit patches to Twisted it's hardly an insurmountable task compared to the other requirements for successfully working a ticket to completion.
I'm not sure why that would be, except that possibly they found a tarball of somebody else's git-svn clone and forgot to update it, or they're confused about the best way to get cloned from some unofficial, no-longer updated mirror. Fixing this probably depends on having the canonical, correct, convenient instructions and advertising them widely.
You edited GitMirror before, you can do it again :).
I'm editing it to include what we've discussed here, as well as a few other things that I researched this afternoon and put into a reply that my MUA ate before it was sent.
I believe the next step should be that somebody with the required permissions should connect to a machine on the same physical network as the SVN server and run:
time git svn clone --stdlayout --prefix="svn/" \ svn+ssh://svn.twistedmatrix.com/svn/Twisted
...then check the load on the SVN server and see if it's going to be an issue to let the clone complete. If the clone completes successfully, then (a) we know about how long it takes, and (b) we have a "seed" repository we can potentially put up for people to download. I'd be happy to download it, check it, and write up some documentation about how people should update it. If it doesn't complete successfully, we should have some helpful error messages, adjust the clone command line and try again.
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
On Wed, Nov 09, 2011 at 09:30:57AM -0500, Tom Davis wrote:
It's worth noting that you aren't *required* to clone all eight trillion Twisted revisions in order to get a working clone. Doing `git svn clone -rN:HEAD <url>` where `N` is some revision number will only clone from that revision.
Yet another useful thing I've missed in the git-svn manpage. Thanks! In fact, it seems you can just specify "-rHEAD" and you'll get a repo with only the latest trunk revision in it. If the resulting repository can gracefully handle updates that add new branches, and new commits on old branches that haven't been imported, this would probably be the best approach for Git-using potential contributors.
On Thu, Nov 10, 2011 at 10:18:03AM +1100, Tim Allen wrote:
In fact, it seems you can just specify "-rHEAD" and you'll get a repo with only the latest trunk revision in it. If the resulting repository can gracefully handle updates that add new branches, and new commits on old branches that haven't been imported, this would probably be the best approach for Git-using potential contributors.
I did a git-svn clone with "-rHEAD" on the day I posted that message, and now when I run "git svn fetch" my repository has the following branches: $ git branch -a * master remotes/svn/multicast-doc-4262 remotes/svn/new-resource-5379 remotes/svn/select-halfclose-3037 remotes/svn/trunk remotes/svn/udp-doread-win-3396-2 remotes/svn/website-template-5380 The "gitk" branch visualisation tool shows me that SVN trunk is currently at r33098 (which merged udp-doread-win-3396-2, although it doesn't show up as a merge commit in git) and all the other branches have been created from that point. So, it looks like it is gracefully handling new branches, which is all we really wanted. Should I update the "GitMirror" page to suggest people run "git svn clone -rHEAD" instead of using the no-longer-updated official mirror? Perhaps the page should also be renamed?
On Nov 13, 2011, at 1:13 AM, Tim Allen wrote:
On Thu, Nov 10, 2011 at 10:18:03AM +1100, Tim Allen wrote:
In fact, it seems you can just specify "-rHEAD" and you'll get a repo with only the latest trunk revision in it. If the resulting repository can gracefully handle updates that add new branches, and new commits on old branches that haven't been imported, this would probably be the best approach for Git-using potential contributors.
I did a git-svn clone with "-rHEAD" on the day I posted that message, and now when I run "git svn fetch" my repository has the following branches:
$ git branch -a * master remotes/svn/multicast-doc-4262 remotes/svn/new-resource-5379 remotes/svn/select-halfclose-3037 remotes/svn/trunk remotes/svn/udp-doread-win-3396-2 remotes/svn/website-template-5380
The "gitk" branch visualisation tool shows me that SVN trunk is currently at r33098 (which merged udp-doread-win-3396-2, although it doesn't show up as a merge commit in git) and all the other branches have been created from that point. So, it looks like it is gracefully handling new branches, which is all we really wanted.
Should I update the "GitMirror" page to suggest people run "git svn clone -rHEAD" instead of using the no-longer-updated official mirror? Perhaps the page should also be renamed?
Sounds like this is a better idea than what we're advising people to do now, although it also sounds like we should add a post-commit hook to push to tell our local bzr mirror to 'git svn fetch' and then the official mirror will be a good idea again. (And possibly something with pushing to github? I don't know. Someone who cares about Git should set it up, not me. :))
On Sun, Nov 13, 2011 at 09:20:46PM -0500, Glyph Lefkowitz wrote:
On Nov 13, 2011, at 1:13 AM, Tim Allen wrote:
Should I update the "GitMirror" page to suggest people run "git svn clone -rHEAD" instead of using the no-longer-updated official mirror? Perhaps the page should also be renamed?
Sounds like this is a better idea than what we're advising people to do now,
I'll update the page, then.
although it also sounds like we should add a post-commit hook to push to tell our local bzr mirror to 'git svn fetch' and then the official mirror will be a good idea again.
I'm not sure whether an official mirror is a good idea - it's another service that would need to be maintained, and it seems that among Twisted core devs there's not a lot of interest or expertise in maintaining it. If Git-using contributors can take care of things themselves without adding any extra administrative load on Twisted's volunteers, what use would an official Git mirror be?
On 03:47 am, screwtape@froup.com wrote:
On Sun, Nov 13, 2011 at 09:20:46PM -0500, Glyph Lefkowitz wrote:
On Nov 13, 2011, at 1:13 AM, Tim Allen wrote:
Should I update the "GitMirror" page to suggest people run "git svn clone -rHEAD" instead of using the no-longer-updated official mirror? Perhaps the page should also be renamed?
Sounds like this is a better idea than what we're advising people to do now,
I'll update the page, then.
although it also sounds like we should add a post-commit hook to push to tell our local bzr mirror to 'git svn fetch' and then the official mirror will be a good idea again.
I'm not sure whether an official mirror is a good idea - it's another service that would need to be maintained, and it seems that among Twisted core devs there's not a lot of interest or expertise in maintaining it. If Git-using contributors can take care of things themselves without adding any extra administrative load on Twisted's volunteers, what use would an official Git mirror be?
The obvious answer is that having one mirror to point people at is better than letting them wonder amongst a forest of dozens of mirrors. On the other hand, maybe Git users prefer the latter scenario. A number of people have asked for an official Git mirror, though. If no one wants this anymore, then by all means let's forget about it. Jean-Paul
On Nov 13, 2011, at 11:39 PM, exarkun@twistedmatrix.com wrote:
I'm not sure whether an official mirror is a good idea - it's another service that would need to be maintained, and it seems that among Twisted core devs there's not a lot of interest or expertise in maintaining it. If Git-using contributors can take care of things themselves without adding any extra administrative load on Twisted's volunteers, what use would an official Git mirror be?
The obvious answer is that having one mirror to point people at is better than letting them wonder amongst a forest of dozens of mirrors. On the other hand, maybe Git users prefer the latter scenario. A number of people have asked for an official Git mirror, though. If no one wants this anymore, then by all means let's forget about it.
Tim: you're right that there isn't much interest among the current Twisted core development team. But the whole point of having a Git mirror (and a presence on Github, which I think is the next step) is to attract new developers to this community. That's why the topic of this thread is "Twisted Project Jobs Volunteer". We're asking for someone with expertise in this area to step up, volunteer to help maintain this mirror, which should help us attract more people who are interested in the same going forward. Is that person you? You're already maintaining the wiki page - and your participation in this thread has probably taken more time than the setup would have, if you have the relevant knowledge :). Is there something you're missing? Some administrative credential, perhaps? Information about where the relevant code lives? If you're up for continuing on this, I'm sure we can get you whatever you need :). Thanks, -glyph
But the whole point of having a Git mirror (and a presence on Github, which I think is the next step) is to attract new developers to this community.
An official presence on Github would be definitely desirable I think, and even more than having a Git mirror technically. Not only attracting new devs, but also user and general public visibility .. how many followers etc etc Also, major competitors are there .. node.js, eventmachine, .. I think - at this point - it's probably fair to say Github has surpassed other OSS collaboration places once popular .. i.e. sourceforge. (I'm not affiliated with Github in any way .. just my impression).
placing in Github is almost a must for attracting developers... At least, it is easy to check the codes... On Mon, Nov 14, 2011 at 4:43 PM, Tobias Oberstein < tobias.oberstein@tavendo.de> wrote:
But the whole point of having a Git mirror (and a presence on Github, which I think is the next step) is to attract new developers to this community.
An official presence on Github would be definitely desirable I think, and even more than having a Git mirror technically.
Not only attracting new devs, but also user and general public visibility .. how many followers etc etc
Also, major competitors are there .. node.js, eventmachine, ..
I think - at this point - it's probably fair to say Github has surpassed other OSS collaboration places once popular .. i.e. sourceforge. (I'm not affiliated with Github in any way .. just my impression).
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
On Mon, Nov 14, 2011 at 12:22:59AM -0500, Glyph wrote:
Tim: you're right that there isn't much interest among the current Twisted core development team. But the whole point of having a Git mirror (and a presence on Github, which I think is the next step) is to attract new developers to this community.
That's why the topic of this thread is "Twisted Project Jobs Volunteer". We're asking for someone with expertise in this area to step up, volunteer to help maintain this mirror, which should help us attract more people who are interested in the same going forward.
There is a thing here that worries me, although I'm not sure I can express it clearly without sounding crazy. Back in the days when CVS and SVN were king, the only way you could interact with a project was by submitting patches, and since only commiters interacted directly with the master repository, it didn't really matter much how branches and merges were handled. As long as you kept things in a way that made sense to you, that was OK - nobody else would see it. Since Git is a distributed VCS, suddenly everybody has access to everybody else's repositories, up close and personal, and suddenly (like when any subjective matter is discussed by a large group of people), people have *opinions* about other people's repositories, and there are *fashions* and *best practices* and all that stuff. I'm not a Github user myself, so I don't know this first hand, but I as I understand it the Github community is has even more social expectations, like pull requests and the Github issue tracker. It's very well to say "make git mirror, push to Github, get new contributors", but I think there's a social impedance mismatch here that's going to cause problems, or at least make people wary because Twisted's Github project behaves weirdly and differently from other Github projects they're used to. Some examples that I can think of: - The most obvious example: in Git, when you merge a branch to trunk, you get a merge commit; in SVN (at least the way Twisted uses it) you just get an ordinary commit that squashes together all the branch commits. That's not a technical problem, but the difference between the Twisted commit graph and an ordinary commit graph is a "something's not right" warning. - In Git, the cultural expectation is "submit a sequence of patches"; Twisted generally wants all your changes in a single patch, since the divisions will be lost on merge anyway. - In Git, if I develop on a branch, then submit that branch as a patch sequence that gets applied by the repository owner, there's a good chance that when I 'git pull', git will recognise those patches as 'my' patches and can rebase my branch intelligently. When those patches have gone via git svn, they seem to have changed enough that rebasing my branch causes horrible merge conflicts. - In Git, you'd generally only create one branch for a patch series, and occasionally rebase it to keep up with trunk changes. The Twisted process seems to favour creating completely new branches (foo-1234, foo-1234-2, foo-1234-3, etc.) to handle trunk changes. - As mentioned, Github merge requests and the Github issue tracker. None of these are show stoppers, they're annoyances at worst, and could be easily explained in documentation. But who will write that documentation? Who will tirelessly explain the differences between the Git world and the Twisted world on the mailing list and #twisted, poll for merge requests and redirect them to Trac, forever? TL;DR: Github users have expectations of how to interact with projects. Twisted can make it easy for Github users to contribute by meeting those expectations, switching from SVN to Git, and changing the UQDS to match. Keeping things the way they are and adding a Git mirror is probably not going to have the desired effect without a lot of effort on somebody's part.
Is that person you? You're already maintaining the wiki page - and your participation in this thread has probably taken more time than the setup would have, if you have the relevant knowledge :). Is there something you're missing? Some administrative credential, perhaps? Information about where the relevant code lives? If you're up for continuing on this, I'm sure we can get you whatever you need :).
Updating a wiki-page is not terribly onerous because it's bounded: solve a problem by reading some documentation, write some more documentation, done. Being the liaison between Twisted core developers and every Git user who might want to contribute is unbounded... or at least, very large and always growing as the number of Twisted devs and Git users increases. I've not forgotten that I have/had Twisted commit access, and coming back to help on a more regular basis is definitely on my list of things to do, although it's pushed down a fair way at the moment. However, even "volunteer for Twisted" was right at the top of the list, I'd be a mug to sign up for such an open-ended responsibility. :)
On 14/11/11 11:55, Tim Allen wrote:
TL;DR: Github users have expectations of how to interact with projects. Twisted can make it easy for Github users to contribute by meeting those expectations, switching from SVN to Git, and changing the UQDS to match. Keeping things the way they are and adding a Git mirror is probably not going to have the desired effect without a lot of effort on somebody's part.
This analysis is spot-on IMO. I am a git and GitHub user, but merely putting the repo somewhere public is about 5% of the benefit, and risks creating expectations you can't (and won't) satisfy. I'd love it if you guys move away from "attach a .patch file to Trac ticket" as the submission workflow - and I think GitHub has great tools for this. But if you're not going to do that, then a shallow clone (which I didn't know about) will fill the need: # run git svn shallow clone git branch my-local-stuff git diff master > stuff.patch # submit to trac # reply: "ok, please create all future patches against branch x-1-2" # git svn update - pulls in the aforementioned branch # hack away git diff x-1-2 > stuff2.patch Cheers, Phil
On Nov 14, 2011, at 6:55 AM, Tim Allen wrote:
It's very well to say "make git mirror, push to Github, get new contributors", but I think there's a social impedance mismatch here that's going to cause problems, or at least make people wary because Twisted's Github project behaves weirdly and differently from other Github projects they're used to.
You're right, of course, but lots of other projects (Django comes to mind) have a Github presence without using Github or Git as their primary development tool. See here: <https://github.com/django>. We already have <https://github.com/twisted>, it's just broken; despite the brokenness it has 14 watchers and 5 forks _anyway_, so clearly people want to use it. This is definitely worse than having a mirror that was updated and working correctly.
I've not forgotten that I have/had Twisted commit access, and coming back to help on a more regular basis is definitely on my list of things to do, although it's pushed down a fair way at the moment. However, even "volunteer for Twisted" was right at the top of the list, I'd be a mug to sign up for such an open-ended responsibility. :)
Welcome to open source. It's all a never-ending thankless slog :-). Really the most important thing here though is just to get the automatic mirroring initially set up, not the never-ending ambassadorial work. That way git users wouldn't _need_ elaborate instructions as to what to clone and how; if we just say "get twisted from github" and have that automatically updated it would be easier for everyone. -glyph
On Mon, Nov 14, 2011 at 10:33 AM, Glyph <glyph@twistedmatrix.com> wrote:
On Nov 14, 2011, at 6:55 AM, Tim Allen wrote:
It's very well to say "make git mirror, push to Github, get new contributors", but I think there's a social impedance mismatch here that's going to cause problems, or at least make people wary because Twisted's Github project behaves weirdly and differently from other Github projects they're used to.
You're right, of course, but lots of other projects (Django comes to mind) have a Github presence without using Github or Git as their primary development tool. See here: <https://github.com/django>. We already have <https://github.com/twisted>, it's just broken; despite the brokenness it has 14 watchers and 5 forks _anyway_, so clearly people want to use it. This is definitely worse than having a mirror that was updated and working correctly.
I've not forgotten that I have/had Twisted commit access, and coming back to help on a more regular basis is definitely on my list of things to do, although it's pushed down a fair way at the moment. However, even "volunteer for Twisted" was right at the top of the list, I'd be a mug to sign up for such an open-ended responsibility. :)
Welcome to open source. It's all a never-ending thankless slog :-). Really the most important thing here though is just to get the automatic mirroring initially set up, not the never-ending ambassadorial work. That way git users wouldn't _need_ elaborate instructions as to what to clone and how; if we just say "get twisted from github" and have that automatically updated it would be easier for everyone.
JP asked me to say something, so... I come from FreeDesktop. We have a git-driven development process which doesn't depend on Github. There is a cgit (http://hjemli.net/git/cgit/about/) instance running on fd.o (http://cgit.freedesktop.org/) which covers everybody's personal and project repos. The contribution process is simple and straightforward. Patches are sent in through the project mailing lists. People can also send patches through auxiliary channels like pastebins and IRC or the Bugzilla, although that's discouraged. When contributors become prolific enough, they can apply for account access, which lets them host repos on fd.o through the magic of userdirs. Code is meritocratic and community-based; when in doubt, a committer can ask for code review. It varies from project to project; fd.o is a *big* umbrella. Branches are very common for contested or complex changes; look at e.g. mesa/mesa for an example of -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson <MostAwesomeDude@gmail.com>
On Mon, Nov 14, 2011 at 10:44 AM, Corbin Simpson <mostawesomedude@gmail.com> wrote:
On Mon, Nov 14, 2011 at 10:33 AM, Glyph <glyph@twistedmatrix.com> wrote:
On Nov 14, 2011, at 6:55 AM, Tim Allen wrote:
It's very well to say "make git mirror, push to Github, get new contributors", but I think there's a social impedance mismatch here that's going to cause problems, or at least make people wary because Twisted's Github project behaves weirdly and differently from other Github projects they're used to.
You're right, of course, but lots of other projects (Django comes to mind) have a Github presence without using Github or Git as their primary development tool. See here: <https://github.com/django>. We already have <https://github.com/twisted>, it's just broken; despite the brokenness it has 14 watchers and 5 forks _anyway_, so clearly people want to use it. This is definitely worse than having a mirror that was updated and working correctly.
I've not forgotten that I have/had Twisted commit access, and coming back to help on a more regular basis is definitely on my list of things to do, although it's pushed down a fair way at the moment. However, even "volunteer for Twisted" was right at the top of the list, I'd be a mug to sign up for such an open-ended responsibility. :)
Welcome to open source. It's all a never-ending thankless slog :-). Really the most important thing here though is just to get the automatic mirroring initially set up, not the never-ending ambassadorial work. That way git users wouldn't _need_ elaborate instructions as to what to clone and how; if we just say "get twisted from github" and have that automatically updated it would be easier for everyone.
JP asked me to say something, so...
I come from FreeDesktop. We have a git-driven development process which doesn't depend on Github. There is a cgit (http://hjemli.net/git/cgit/about/) instance running on fd.o (http://cgit.freedesktop.org/) which covers everybody's personal and project repos.
The contribution process is simple and straightforward. Patches are sent in through the project mailing lists. People can also send patches through auxiliary channels like pastebins and IRC or the Bugzilla, although that's discouraged. When contributors become prolific enough, they can apply for account access, which lets them host repos on fd.o through the magic of userdirs. Code is meritocratic and community-based; when in doubt, a committer can ask for code review. It varies from project to project; fd.o is a *big* umbrella. Branches are very common for contested or complex changes; look at e.g. mesa/mesa for an example of
Boy, thanks Gmail. I really appreciated that. Anyway, mesa/mesa has dozens upon dozens of branches. Just like Twisted. It works well. So, Github adds *zero* fun to this. Its issue tracker is roughly as unfun as Bugzilla. Pull requests are frustrating; I find myself just pulling their code using standard git tools and ignoring the auto-merge tool. I don't really enjoy having messages sent to me *through* Github when we could just use email, like civilized people. I view Github as a source of bandwidth and space to avoid having to host my numerous personal repositories on a personal server. It's a convenience and crutch. TM is not short of resources; there certainly could be a git.tm.com or cgit.tm.com and userdir-powered repositories. Admittedly, this is at odds with the current direction towards LP and Bazaar, but I think it's a lot better than letting us rely on Github. ~ C.
-- When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson <MostAwesomeDude@gmail.com>
-- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson <MostAwesomeDude@gmail.com>
On Nov 14, 2011, at 1:48 PM, Corbin Simpson wrote:
... I think it's a lot better than letting us rely on Github.
I don't want to "rely" on github. I want our official presence there (which is already there) to be current and properly maintained so that people who use Github for other reasons (discovery, convneience, gists, because "social networks" are cool, whatever) have the ability to use it if it's convenient for them to get started writing code. It should be pretty well-known at this point that I don't really like github either, but what I like a lot less than github is losing potential contributors for any reason. -glyph
On Mon, Nov 14, 2011 at 01:33:45PM -0500, Glyph wrote:
Really the most important thing here though is just to get the automatic mirroring initially set up, not the never-ending ambassadorial work. That way git users wouldn't _need_ elaborate instructions as to what to clone and how; if we just say "get twisted from github" and have that automatically updated it would be easier for everyone.
I've done some experimentation, and (as best I can tell) it's impossible to use git-svn to create a sensible SVN → Git conversion of the Twisted repository. This is because of the various, inconsistent branch-naming schemes that have been used over Twisted's long history. As best I can tell, git-svn can import branches that exist at some specific depth in the tree... so if your branches look like this: root | +- branches | +- add-a-feature-1234 +- fix-a-bug-2345 +- release-v1.0.x +- release-v1.1.x ...you can say "git svn clone --branches='branches/*'" and they'll be imported as Git branches. Likewise, if you group your branches in some way: root | +- branches | +- topic-branches | | | +- add-a-feature-1234 | +- fix-a-bug-2345 | +- release-branches | +- v1.0.x +- v1.1.x ...then you can say "git svn clone --branches='branches/*/*'" and they'll all be imported cleanly. Unfortunately, the Twisted repository's "branches" directory contains subdirectories representing branches *and* subdirectories representing groups of branches... and *those* contain both branch directories and branch-group directories. Here are the branch-group directories I've discovered so far: branches/ branches/releases/ branches/releases/conch/ branches/releases/mail/ branches/releases/names/ branches/releases/words/ When I import a range of revisions that happens to include a change to a branch in "branches/releases" (I've been using the range 33049:33062 for testing), git-svn winds up importing the entire "releases" subtree as a branch, which is... suboptimal. If I use the "--ignore-paths" option to ignore everything under "branches/releases", then it still generates the branch and faithfully records all the commits affecting it... but ignores all the files, so when you check out that branch it deletes everything in your working directory. What's really annoying about this is that git itself doesn't care about branch naming, and it's perfectly happy to have "add-a-feature-1234" and "releases/v1.0.x" as branch names. It's just the git-svn tool not being flexible enough. A quick Google doesn't reveal much in the way of other people who have dealt with repository layouts like this, except for one report which basically went "use 'svnadmin dump' to export the repository, use sed to rewrite all the paths, load the dump into a new svn repository and import from there." That sounds like a lot of work to me, and not the sort of thing that could be reliably repeated to keep the two repositories in sync. Perhaps someone should file a bug with the git-svn maintainer, if only they had a bug-tracker. So, would a repository with a huge, bogus "releases" branch be acceptable in an Official Mirror? It's not strictly needed for developing patches, but it *will* create lots of puzzled frowns and annoyance, perhaps from people who want a Git mirror to integrate with their "automatically download new releases" code. Also in the spirit of writing things down so future contributors can figure things out, I note the Git FAQ on the Git Wiki has a "How do I mirror a SVN repository to git?" question: https://git.wiki.kernel.org/articles/g/i/t/GitFaq_ebc3.html
On 16/11/11 13:13, Tim Allen wrote:
On Mon, Nov 14, 2011 at 01:33:45PM -0500, Glyph wrote:
Really the most important thing here though is just to get the automatic mirroring initially set up, not the never-ending ambassadorial work. That way git users wouldn't _need_ elaborate instructions as to what to clone and how; if we just say "get twisted from github" and have that automatically updated it would be easier for everyone.
I've done some experimentation, and (as best I can tell) it's impossible to use git-svn to create a sensible SVN → Git conversion of the Twisted repository.
There's a tool called svn-all-fast-export [1] that in my experience is much faster and is much more flexible. It has some issues: * the documentation is scarce, but after some googling it's possible to get the hang of it * it's a one-off conversion (!) * AFAIR it requires access to the actual SVN repository, not just a checkout Perhaps it would be feasible for you to get a tarball of the SVN repo, write a config file for svn-all-fast-export that will make all the required branches and tags be created and then pick up with git-svn from that (I'm also not 100% sure that "picking up" will be possible). Anyway, just wanted to point out a tool that's been used by for instance Gnome to move from SVN to git and that I had some positive experience with personally. Cheers, Jan [1] http://repo.or.cz/w/svn-all-fast-export.git
On Wed, Nov 16, 2011 at 11:13:50PM +1100, Tim Allen wrote:
On Mon, Nov 14, 2011 at 01:33:45PM -0500, Glyph wrote:
Really the most important thing here though is just to get the automatic mirroring initially set up, not the never-ending ambassadorial work. That way git users wouldn't _need_ elaborate instructions as to what to clone and how; if we just say "get twisted from github" and have that automatically updated it would be easier for everyone.
I've done some experimentation, and (as best I can tell) it's impossible to use git-svn to create a sensible SVN → Git conversion of the Twisted repository. This is because of the various, inconsistent branch-naming schemes that have been used over Twisted's long history.
Actually, maybe git-svn by itself is not smart enough to handle all the possible cases and "weird" repository schemes like Twisted's one. However, I think it should be possible with a second pass script to have a pretty good, or at least better, conversion. If you init the repository with "--prefix=svn/ --trunk=trunk", I think you will got a working copy with trunk, and all the branches and tags as references in the "svn/" namespace. Then, with a script smart enough, which looks through the references in "svn/branches/" and "svn/tags/", it can create the right branches and tags like "--stdlayout" would do if the scheme was compatible. The difficulty I think lies into the "smart enough", but if we can't find a way with this, I don't know how git-svn would be capable of. As an example of what I mean, if we want to import the tags from the Subversion repository, the job will consist in: 1. list all of the svn/tags/releases/release-* references 2. strip the "release-" prefix to keep only the "x.y.z" scheme 3. for each tag, if it doesn't already exit, "git tag x.y.z svn/tags/releases/release-x.y.z" Maybe it needs to be even smarter for branches, but the final step will only be "git branch BRANCH_NAME SVN_REFERENCE", which might end up with a cleaner Git repository than the original Subversion repository... If some help is needed, I'm willing to help too. I'm not sure to fully understand where and how this conversion is heading to. My 2 cents, Jonathan
On Wed, Nov 16, 2011 at 6:41 AM, Jonathan Ballet <jon@multani.info> wrote:
On Wed, Nov 16, 2011 at 11:13:50PM +1100, Tim Allen wrote:
I've done some experimentation, and (as best I can tell) it's impossible to use git-svn to create a sensible SVN → Git conversion of the Twisted repository. This is because of the various, inconsistent branch-naming schemes that have been used over Twisted's long history.
Actually, maybe git-svn by itself is not smart enough to handle all the possible cases and "weird" repository schemes like Twisted's one.
Yes, git-svn by itself cannot handle Twisted's repository both because of the repository layout that is different from what it expects, but also because if git-svn tries to mirror a repository with a large number of branches all at once it slows to a molasses-in-January crawl.
However, I think it should be possible with a second pass script to have a pretty good, or at least better, conversion.
The solution that I've come up with is to use git-svn to create a separate Git repository for each branch, and then git-push that branch into a central Git repository. This does burn *a lot* of disk space, but only one person needs to do it - everyone else can clone the central repository. The initial setup takes a while, but subsequent runs should be relatively fast. You can see the converted repository I'm building at: https://github.com/jcollie/twisted It's still in the process of building up so not all the branches are there yet. I've put the script that I'm using here: https://github.com/jcollie/twisted-svn-convert One feature that I'd like to add before calling this final is converting SVN usernames to "proper" names/email addresses like Git prefers to use. I use a similar script to mirror the Asterisk SVN repository with some good results: https://github.com/jcollie/asterisk -- Jeff Ollie
On Wed, Nov 16, 2011 at 08:17:51AM -0600, Jeffrey Ollie wrote:
The solution that I've come up with is to use git-svn to create a separate Git repository for each branch, and then git-push that branch into a central Git repository. This does burn *a lot* of disk space, but only one person needs to do it - everyone else can clone the central repository. The initial setup takes a while, but subsequent runs should be relatively fast.
You can see the converted repository I'm building at:
https://github.com/jcollie/twisted
It's still in the process of building up so not all the branches are there yet.
Oooh. That's looking pretty good. As you say, not all the branches are there, and none of the tags, but I can see you've already successfully imported some of the tricky release branches.
I've put the script that I'm using here:
https://github.com/jcollie/twisted-svn-convert
One feature that I'd like to add before calling this final is converting SVN usernames to "proper" names/email addresses like Git prefers to use.
I see your script repository already has the beginnings of such a mapping file; unfortunately you've already filled in most of the names I recognise, and I don't know if there's any other authoritative list of such information (and of course, it would need to be updated as Twisted adds new committers). The "how to mirror Git to SVN" section of the Git FAQ includes information on how to take a cloned git repository and add git-svn magic so you can commit to the original upstream repository; I guess that wouldn't really work with your custom import script. I think this would be a much better base for an Official Twisted Git Mirror than anything I've come up with so far. How difficult would it be for somebody unfamiliar with Git (such as, say, the Twisted core devs) to keep running?
On Thu, 2011-11-17 at 14:46 +1100, Tim Allen wrote:
On Wed, Nov 16, 2011 at 08:17:51AM -0600, Jeffrey Ollie wrote: [..snip..]
One feature that I'd like to add before calling this final is converting SVN usernames to "proper" names/email addresses like Git prefers to use.
I see your script repository already has the beginnings of such a mapping file; unfortunately you've already filled in most of the names I recognise, and I don't know if there's any other authoritative list of such information (and of course, it would need to be updated as Twisted adds new committers).
These might be a good start: http://twistedmatrix.com/trac/wiki/TwistedMatrixLaboratories http://twistedmatrix.com/trac/browser/trunk/twisted/topfiles/CREDITS However the latter hasn't changed in 5 years, the former probably also isn't complete and people's e-mail addresses might not map their (current) Git(Hub) one. -- ralphm
On Thu, Nov 17, 2011 at 4:03 AM, Ralph Meijer <twisted@ralphm.ik.nu> wrote:
http://twistedmatrix.com/trac/wiki/TwistedMatrixLaboratories http://twistedmatrix.com/trac/browser/trunk/twisted/topfiles/CREDITS
However the latter hasn't changed in 5 years, the former probably also isn't complete and people's e-mail addresses might not map their (current) Git(Hub) one.
Those are most definitely not complete. Kevin Horn
On Wed, Nov 16, 2011 at 9:46 PM, Tim Allen <screwtape@froup.com> wrote:
On Wed, Nov 16, 2011 at 08:17:51AM -0600, Jeffrey Ollie wrote:
It's still in the process of building up so not all the branches are there yet.
Oooh. That's looking pretty good. As you say, not all the branches are there, and none of the tags, but I can see you've already successfully imported some of the tricky release branches.
The problem with tags in SVN is that there really aren't any, there are just directories that are used as tags by convention.
The "how to mirror Git to SVN" section of the Git FAQ includes information on how to take a cloned git repository and add git-svn magic so you can commit to the original upstream repository; I guess that wouldn't really work with your custom import script.
Not really, and from what I've seen it's very tricky to get it to work properly anyway.
I think this would be a much better base for an Official Twisted Git Mirror than anything I've come up with so far. How difficult would it be for somebody unfamiliar with Git (such as, say, the Twisted core devs) to keep running?
Customize a few variables and then it's just a matter of putting it in a cron job. I should add some sort of locking as well so that if one run lasts too long a subsequent run won't step all over the previous one. -- Jeff Ollie
On Sun, Nov 13, 2011 at 09:20:46PM -0500, Glyph Lefkowitz wrote:
On Nov 13, 2011, at 1:13 AM, Tim Allen wrote:
Should I update the "GitMirror" page to suggest people run "git svn clone -rHEAD" instead of using the no-longer-updated official mirror? Perhaps the page should also be renamed?
Sounds like this is a better idea than what we're advising people to do now,
GitMirror page updated. I discovered a wrinkle, though: it turns out that "git svn clone -rHEAD" only works if the HEAD of the SVN repo happens to be a commit to trunk. If the HEAD happens to be a commit on a branch, tag, or anything else, it only downloads the contents of the branch, tries to set up the trunk and can't find it, then collapses in a heap. I've added a step that uses "svn info" to find the last trunk commit, so the user can substitute that revision number into the "git svn clone" command. I'd appreciate it if anyone with a vague familiarity with Git could read over the page and tell me if there's anything I can improve.
On Wed, Nov 9, 2011 at 6:49 AM, Tim Allen <screwtape@froup.com> wrote:
I believe the next step should be that somebody with the required permissions should connect to a machine on the same physical network as the SVN server and run:
time git svn clone --stdlayout --prefix="svn/" \ svn+ssh://svn.twistedmatrix.com/svn/Twisted
Which will fail spectacularly because the Twisted SVN repository does not use the standard layout that git-svn is expecting. In particular the branches/releases and tags/releases directory will really mess things up. -- Jeff Ollie
On Wed, Nov 09, 2011 at 01:39:44PM -0600, Jeffrey Ollie wrote:
On Wed, Nov 9, 2011 at 6:49 AM, Tim Allen <screwtape@froup.com> wrote:
I believe the next step should be that somebody with the required permissions should connect to a machine on the same physical network as the SVN server and run:
time git svn clone --stdlayout --prefix="svn/" \ svn+ssh://svn.twistedmatrix.com/svn/Twisted
Which will fail spectacularly because the Twisted SVN repository does not use the standard layout that git-svn is expecting. In particular the branches/releases and tags/releases directory will really mess things up.
Yes, branches/releases and tags/releases would need to be specially handled; I'm not sure if it's possible to import them as just more branches and tags, or if they'd have to be removed entirely. I wouldn't call that a spectactular failure, though - you should still have trunk and the various feature branches, which is all you need to submit patches.
participants (20)
-
Adi Roiban -
Antoine Pitrou -
Corbin Simpson -
Dave Peticolas -
exarkun＠twistedmatrix.com -
gelin yan -
Glyph -
Glyph Lefkowitz
-
Ivan Kozik -
Jan Urbański -
Jeffrey Ollie -
Jonathan Ballet -
Jonathan Lange -
Kevin Horn -
Laurens Van Houtven -
Phil Mayers -
Ralph Meijer -
Tim Allen -
Tobias Oberstein -
Tom Davis