You are viewing a plain text version of this content. The canonical link for it is here.
Posted to infrastructure-dev@apache.org by Justin Erenkrantz <ju...@erenkrantz.com> on 2008/05/20 06:37:38 UTC
Re: svn commit: r658061 - /infrastructure/trunk/httpd-conf/vc.eu.apache.org/dontdothat.conf
On Tue, May 20, 2008 at 2:54 AM, <jo...@apache.org> wrote:
> Author: joes
> Date: Mon May 19 17:54:24 2008
> New Revision: 658061
>
> Log:
> disable dontdothat to allow git-svn thru
>
> Modified:
> infrastructure/trunk/httpd-conf/vc.eu.apache.org/dontdothat.conf
>
> Modified: infrastructure/trunk/httpd-conf/vc.eu.apache.org/dontdothat.conf
> ==============================================================================
> --- infrastructure/trunk/httpd-conf/vc.eu.apache.org/dontdothat.conf (original)
> +++ infrastructure/trunk/httpd-conf/vc.eu.apache.org/dontdothat.conf Mon May 19 17:54:24 2008
> @@ -1,2 +1,2 @@
> [recursive-actions]
> -/ = deny
> +
Since harmonia should always be permitting replay (irrespective of the
config), do you know what operation is exactly failing against /?
git-svn should be only trying to do log and replay. Anything else is
brokenness on git-svn's part. According to clkao and the SVK folks,
log and replay are all svk needs to work successfully - therefore,
git-svn should not need anything more than svk...
I'm not comfortable disabling all DoS protection just because git-svn
doesn't know how to play well with others... It'd be too easy for a
stupid user to hit 'svn co http://svn.eu.apache.org/repos/asf/' and
try to check out everything - IMO, mod_dontdothat needs to be in place
to prevent that. -- justin
Re: tags not being created by git-svn (was: git-svnRe: svn commit: r658061 - /infrastructure/trunk/httpd-conf/vc.eu.apache.org/dontdothat.conf)
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, May 22, 2008 at 12:13 AM, Grzegorz Kossakowski
<gk...@apache.org> wrote:
> However, I see some weirdness. The biggest problem is that git-svn didn't
> create regular git branches that can be found in Cocoon's svn repository.
> Moreover, it seems to handle branches and tags the same way as remote
> branches. I think this explains what I mean:
> [...]
> Is it expected behaviour of git-svn?
Yes.
> Do you know how to deal with such situation? (I'm still new to git-svn)
Depends on what you want to do. The branch data (even if remote) is
included in the git clone (by fetch), so you can browse, checkout,
merge, diff, etc. the code in the branches.
I'm not sure if dcommit works on an svn branch or just the trunk.
BR,
Jukka Zitting
Re: tags not being created by git-svn (was: git-svnRe: svn commit:
r658061 - /infrastructure/trunk/httpd-conf/vc.eu.apache.org/dontdothat.conf)
Posted by Santiago Gala <sa...@gmail.com>.
El mié, 21-05-2008 a las 23:13 +0200, Grzegorz Kossakowski escribió:
> Santiago Gala pisze:
> >
> > I typically use separate init / fetch because of the probability of
> > failure. I'm not sure if, after some time, clonce can be restarted by
> > just "cd <dir>; git svn fetch", but:
> >
> > * after git init succeeds, git fetch is fully restartable
> > * most problems with root lookups occur when fishing for history, once
> > git svn fetch starts moving up revisions it is quite probable that it
> > will finish fetching without problems, though it might depends on new
> > resources being moved into the project space "out of the blue", which it
> > needs to track history.
>
> Just FYI: I seem to successfully clone Cocoon's repository using git-svn clone command.
> However, I see some weirdness. The biggest problem is that git-svn didn't create regular git
> branches that can be found in Cocoon's svn repository. Moreover, it seems to handle branches and
> tags the same way as remote branches. I think this explains what I mean:
> > git-branch
> * master
> > git-branch -r
> BRANCH_2_1_X
> bin
> butterfly
> cocoon-2.2
> cocoon-forms-1.0.0
> cocoon-forms-1.0.0@389838
>
> <snip/>
>
> tags/ASF_20_BEFORE
> tags/ASF_20_SCRATCHPAD_AUTO
> tags/ASF_20_SRC_AUTO
> tags/RC_2_1_10
> tags/RELEASE_2_1
> <snip/>
> tags/trunk_before_flattening
> testdata
> tools
> trunk
>
> Is it expected behaviour of git-svn?
>
Well, WRT branches, they are *remote*, i.e. on the subversion
repository. I guess you can create a local one on the remote commit, do
some work on it and dcommit, but I have not yet tried this use casa.
WRT tags, I have converted them to git tags in some repositories I
track, but there is a danger: nothing impedes you to commit a change to
a subversion tag, for what I know. Subversion tags are no more than a
point in the version tree. OTOH, git tags are different animals, just a
pointer to a commit in a branch with optional crypto and metadata. So,
converting them into tags will make a problem tracking the tag if
someone commits on top of if later on.
> Do you know how to deal with such situation? (I'm still new to git-svn)
>
If you want them as git tags, something like:
for tag in $(git branch -r | grep tags | grep -v @) ; do echo git tag
${tag/tags\//}; done
(without the "echo") will create a tag on top of every branch that has a
name with "tags" on it. The negative grep on "@" is to take care of
working tags created by git-svn to track code movements, which I can see
in portals-bridges, which got moved quite a bit. You could delete the
branches after, with the caveat about ulterior modifications off this
tag on the server.
> Thanks for any help.
>
--
Santiago Gala
http://memojo.com/~sgala/blog/
tags not being created by git-svn (was: git-svnRe: svn commit: r658061
- /infrastructure/trunk/httpd-conf/vc.eu.apache.org/dontdothat.conf)
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Santiago Gala pisze:
>
> I typically use separate init / fetch because of the probability of
> failure. I'm not sure if, after some time, clonce can be restarted by
> just "cd <dir>; git svn fetch", but:
>
> * after git init succeeds, git fetch is fully restartable
> * most problems with root lookups occur when fishing for history, once
> git svn fetch starts moving up revisions it is quite probable that it
> will finish fetching without problems, though it might depends on new
> resources being moved into the project space "out of the blue", which it
> needs to track history.
Just FYI: I seem to successfully clone Cocoon's repository using git-svn clone command.
However, I see some weirdness. The biggest problem is that git-svn didn't create regular git
branches that can be found in Cocoon's svn repository. Moreover, it seems to handle branches and
tags the same way as remote branches. I think this explains what I mean:
> git-branch
* master
> git-branch -r
BRANCH_2_1_X
bin
butterfly
cocoon-2.2
cocoon-forms-1.0.0
cocoon-forms-1.0.0@389838
<snip/>
tags/ASF_20_BEFORE
tags/ASF_20_SCRATCHPAD_AUTO
tags/ASF_20_SRC_AUTO
tags/RC_2_1_10
tags/RELEASE_2_1
<snip/>
tags/trunk_before_flattening
testdata
tools
trunk
Is it expected behaviour of git-svn?
Do you know how to deal with such situation? (I'm still new to git-svn)
Thanks for any help.
--
Grzegorz Kossakowski
Re: svn commit: r658061 -
/infrastructure/trunk/httpd-conf/vc.eu.apache.org/dontdothat.conf
Posted by Santiago Gala <sa...@gmail.com>.
El mar, 20-05-2008 a las 22:12 +0200, Grzegorz Kossakowski escribió:
> Jukka Zitting pisze:
> > Hi,
> >
> > On Tue, May 20, 2008 at 10:39 PM, Grzegorz Kossakowski
> > <gk...@apache.org> wrote:
> >> I've just tried to run following command:
> >> git-svn clone http://svn.eu.apache.org/repos/asf/cocoon/ --stdlayout
> >> --log-window-size=10000
> >>
> >> and it started to clone without any problems. Is mod_dontdothat disabled
> >> now?
> >
I typically use separate init / fetch because of the probability of
failure. I'm not sure if, after some time, clonce can be restarted by
just "cd <dir>; git svn fetch", but:
* after git init succeeds, git fetch is fully restartable
* most problems with root lookups occur when fishing for history, once
git svn fetch starts moving up revisions it is quite probable that it
will finish fetching without problems, though it might depends on new
resources being moved into the project space "out of the blue", which it
needs to track history.
Regards
Santiago
> > Also, earlier today I was able to finish my git-svn clone of Apache
> > Jackrabbit without problems. Earlier it failed with the 403 error.
>
> Hmmm, if it was kept in that state (configuration) until tomorrow I could finally finish cloning of
> Cocoon.
>
> Any chance for that?
>
> PS. Even if I achieve my main goal (cloning of Cocoon) I'll be still willing to help with
> establishing some official support for git-svn. I mean here debugging, providing necessary dumps
> from wireshark, etc.
>
--
Santiago Gala
http://memojo.com/~sgala/blog/
Re: svn commit: r658061 - /infrastructure/trunk/httpd-conf/vc.eu.apache.org/dontdothat.conf
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Jukka Zitting pisze:
> Hi,
>
> On Tue, May 20, 2008 at 10:39 PM, Grzegorz Kossakowski
> <gk...@apache.org> wrote:
>> I've just tried to run following command:
>> git-svn clone http://svn.eu.apache.org/repos/asf/cocoon/ --stdlayout
>> --log-window-size=10000
>>
>> and it started to clone without any problems. Is mod_dontdothat disabled
>> now?
>
> Also, earlier today I was able to finish my git-svn clone of Apache
> Jackrabbit without problems. Earlier it failed with the 403 error.
Hmmm, if it was kept in that state (configuration) until tomorrow I could finally finish cloning of
Cocoon.
Any chance for that?
PS. Even if I achieve my main goal (cloning of Cocoon) I'll be still willing to help with
establishing some official support for git-svn. I mean here debugging, providing necessary dumps
from wireshark, etc.
--
Grzegorz Kossakowski
Re: svn commit: r658061 - /infrastructure/trunk/httpd-conf/vc.eu.apache.org/dontdothat.conf
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Tue, May 20, 2008 at 10:39 PM, Grzegorz Kossakowski
<gk...@apache.org> wrote:
> I've just tried to run following command:
> git-svn clone http://svn.eu.apache.org/repos/asf/cocoon/ --stdlayout
> --log-window-size=10000
>
> and it started to clone without any problems. Is mod_dontdothat disabled
> now?
Also, earlier today I was able to finish my git-svn clone of Apache
Jackrabbit without problems. Earlier it failed with the 403 error.
BR,
Jukka Zitting
Re: svn commit: r658061 - /infrastructure/trunk/httpd-conf/vc.eu.apache.org/dontdothat.conf
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Justin Erenkrantz pisze:
>
> That isn't enough information to be useful - and that definitely means
> that restricting the block on "/" isn't the right thing to do. Can
> you include the full HTTP request and response that git-svn sees?
> (Use tcpdump, etc.) Does the response include "no soup for you"?
> Otherwise, then it's not mod_dontdothat blocking it. -- justin
Justin,
I've just tried to run following command:
git-svn clone http://svn.eu.apache.org/repos/asf/cocoon/ --stdlayout --log-window-size=10000
and it started to clone without any problems. Is mod_dontdothat disabled now?
--
Grzegorz Kossakowski
Re: svn commit: r658061 - /infrastructure/trunk/httpd-conf/vc.eu.apache.org/dontdothat.conf
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, May 20, 2008 at 10:45 AM, Grzegorz Kossakowski
<gk...@apache.org> wrote:
> Joe and me have been trying to sort this out yesterday but without much
> of success yet. Currently, git-svn fails because it gets 403 response to
> request on '/repos/asf/!svn/vcc/default'. The request body contains
> <update-target>cocoon</update-target> so I guess it should be possible
> to configure mod_dontdothat to allow such requests.
That isn't enough information to be useful - and that definitely means
that restricting the block on "/" isn't the right thing to do. Can
you include the full HTTP request and response that git-svn sees?
(Use tcpdump, etc.) Does the response include "no soup for you"?
Otherwise, then it's not mod_dontdothat blocking it. -- justin
Re: svn commit: r658061 - /infrastructure/trunk/httpd-conf/vc.eu.apache.org/dontdothat.conf
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Justin Erenkrantz wrote:
> Since harmonia should always be permitting replay (irrespective of the
> config), do you know what operation is exactly failing against /?
>
> git-svn should be only trying to do log and replay. Anything else is
> brokenness on git-svn's part. According to clkao and the SVK folks,
> log and replay are all svk needs to work successfully - therefore,
> git-svn should not need anything more than svk...
>
> I'm not comfortable disabling all DoS protection just because git-svn
> doesn't know how to play well with others... It'd be too easy for a
> stupid user to hit 'svn co http://svn.eu.apache.org/repos/asf/' and
> try to check out everything - IMO, mod_dontdothat needs to be in place
> to prevent that. -- justin
>
Joe and me have been trying to sort this out yesterday but without much
of success yet. Currently, git-svn fails because it gets 403 response to
request on '/repos/asf/!svn/vcc/default'. The request body contains
<update-target>cocoon</update-target> so I guess it should be possible
to configure mod_dontdothat to allow such requests.
Therefore, I wouldn't be so sure that it's git-svn fault. I guess this
issue needs more debugging but it looks like all svn admins (especially
Joe) live in different time zone than me so it's rather hard to meet
online. Anyway, can we arrange some meeting on #asfifra ?
For me the best would be Thursday as I have a whole day free.
--
Grzegorz Kossakowski