Re: git-svn+cygwin failed fetch
- From
- Eric Wong <normalperson@yhbt.net>
- Date
- Jul 12, 2007, 18:27 UTC
- Message-ID
- <20070712182754.GB24854@hand.yhbt.net>
- In-Reply-To
- <f9d2a5e10707121049o758109c0l4ebeb08250093ba0@mail.gmail.com>
Russ Dill <russ.dill@gmail.com> wrote:
Show 65 quoted lines
> On 7/11/07, Eric Wong <normalperson@yhbt.net> wrote:
> >Russ Dill <russ.dill@gmail.com> wrote:
> >> On 7/11/07, Eric Wong <normalperson@yhbt.net> wrote:
> >> >Russ Dill <russ.dill@gmail.com> wrote:
> >> >> [...]/src $ mkdir foo
> >> >> [...]/src $ cd foo
> >> >> [...]/src/foo $ git-svn init -t tags -b branches -T trunk
> >> >> https://www.[...].com/svn/foo/bar/bla
> >> >> Initialized empty Git repository in .git/
> >> >> Using higher level of URL: https://www.[...].com/svn/foo/bar/bla =>
> >> >> https://www.[...].com/svn/foo
> >> >>
> >> >> [...]/src/foo $ git-svn fetch
> >> >> config --get svn-remote.svn.url: command returned error: 1
> >> >>
> >> >> [...]/src/foo $ git config --get svn-remote.svn.url
> >> >> https://www.[...].com/svn/foo
> >> >
> >> >Sorry, I can't help here other than recommending a real UNIX with
> >> >fork + pipe + exec and all that fun stuff.
> >> >
> >> >git-svn relies heavily[1] on both input and output pipes of the
> >> >safer-but-made-for-UNIX fork + pipe + exec(@list) variety, so I suspect
> >> >this is just the tip of the iceberg for Windows incompatibilies with
> >> >git-svn...
> >>
> >> Its actually reading and writing quite a bit of stuff from the config
> >> file, so why this one simple command would fail eludes me. Especially
> >> since it wrote it there in the first place. If I comment out the
> >> command_oneline and hardcode the value I know it should return,
> >> git-fetch runs. Its actually been running for several hours now.
> >
> >Wow. That's a pleasant surprise that anything in git-svn works at all
> >on cygwin. I was almost certain git-svn on Windows was a hopeless cause
> >from other chatter I had heard on the mailing list.
> >
> >command_oneline() is used everywhere in that code, so I'm at a total loss
> >as to why it would fail in one place. Can you put a the following lines
> >right before where it was failing?
> >
> > print "GIT_CONFIG: $ENV{GIT_CONFIG} | GIT_DIR: $ENV{GIT_DIR}\n";
> > system('cat', "$ENV{GIT_DIR}/config");
> >
> >And tell me what it outputs?
>
>
> Use of uninitialized value in concatenation (.) or string at
> /usr/bin/git-svn line 1189.
> GIT_CONFIG: | GIT_DIR: .git
> [core]
> repositoryformatversion = 0
> filemode = true
> bare = false
> logallrefupdates = true
> [svn-remote "svn"]
> url = https://www.[...].com/svn/foo
> fetch = bar/bla/trunk:refs/remotes/trunk
> branches = bar/bla/branches/*:refs/remotes/*
> tags = bar/bla/tags/*:refs/remotes/tags/*
> [gui]
> geometry = 864x678+162+162 104 204
>
>
> If I export GIT_CONFIG, then the problem goes away. Much better work
> around then hardcoding svn-remote.svn.urlVery strange. I do set GIT_CONFIG internally in git-svn in a few places and then unset it.
Show 5 quoted lines
> The git-svn fetch died overnight due to an http error. Its restarted > now. There are dozens of branches and tags in the repo, and each one > seems to take about a half hour to and hour to fully fetch. It takes a > similar amount of time to checkout trunk with tortise SVN. The repo is > local, but I don't have direct access to it.
SVN 1.4.4 with a working do_switch() API call should be much faster.
-- Eric Wong