git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Gustaf Hendeby" <hendeby@gmail.com>
To: "Eric Wong" <normalperson@yhbt.net>
Cc: git@vger.kernel.org
Subject: Re: git-svn: surprising behaviors/bugs?
Date: Thu, 29 Nov 2007 10:59:51 +0100	[thread overview]
Message-ID: <bf7b2dda0711290159v49b5bc2elb072b610d2237755@mail.gmail.com> (raw)
In-Reply-To: <20071129081031.GF32277@soma>

On Nov 29, 2007 9:10 AM, Eric Wong <normalperson@yhbt.net> wrote:
> Gustaf Hendeby <hendeby@gmail.com> wrote:
> > 1.  I don't really like svn's committer info, so I got an authorsfile
> > set.  This works great when I'm fetching/dcommitting from the
> > top-directory in my git checkout (the one with .git in), however, if
> > I'm in a subdirectory the authorsfile doesn't kick in and I get the
> > svn commiter info.  This is not a big deal, but a bit surprising and
> > my history gets a bit ugly.
>
> I see you've already fixed that.  Thanks.

Yes, it turned out to be easier than I thought.  The fix indicates
that other options are lost as well, but I don't know how to test for
that or it would have been easier for others to verify the problem.

> > 2.  My second problem involves getting the support in git-svn for tags
> > and branches to work.  Having a standard layout of the svn repository,
> > in this case
> >    /source/project/(trunk|branch|tags)
> > svn clone -s only works as expected sometimes.  Sometimes I only get
> > the revision history, not including any actual content (ie none files
> > of the files under control turns up in git) from the clone.  When I
> > get this problem I usually clone the trunk only, and add tags myself.
> > This is far from optimal, and also error prone.  Other times, the
> > clone works as expected and gives me the tags and branches and all the
> > content.
>
> Any chance there's a BOFH at the other end playing around with
> permissions while you were testing?

This time I think BOFH is innocent, unless for maybe setting up the
SVN repository in a stupid way.

> > I think the problem occurs when I'm not the owner of the svn
> > repository, and only have access (read/write) to the
> > project/(trunk|branch|tag) part, and don't have any access at all to
> > source.  Ie, svn ls works for /source/project and
> > /source/project/trunk etc, but not /source (where I returns 403
> > Forbidden access).  All svn access is through a svn-server that I
> > can't control myself.
>
> I'll have to look into that some other time.

Would be great, thanks, let me know how I can help.  I've tried to
answer your questions about the setup below.

>
> Does `svn log -v' work for /source/project ?

Works just fine.

>
> Am I correct in what you have is currently like this?
>
> [svn-remote "svn"]
>         url = http://domain/
>         branches = source/project/branches/*:refs/remotes/*
>         tags = source/project/tags/*:refs/remotes/tags/*
>         fetch = source/project/trunk:refs/remotes/trunk
>
>
> If so, can you change it to something like this?
>
> [svn-remote "svn"]
>         url = http://domain/source/project
>         branches = branches/*:refs/remotes/*
>         tags = tags/*:refs/remotes/tags/*
>         fetch = trunk:refs/remotes/trunk
>
> And see if that works all the time?

I just made three different setups to get the same (problematic) project.

PLAIN TRUNK (works as expected, but lacks tags/branches)
git svn init https://svn.isy.liu.se/rt/tidefelt/source/shapes shapes.trunk
cd shapes.trunk
git svn fetch  # Now gives me the history of the trunk with all content
cat .git/config
[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
[svn-remote "svn"]
        url = https://svn.isy.liu.se/rt/tidefelt/source/shapes/trunk
        fetch = :refs/remotes/git-svn


WITH STANDARD LAYOUT (gets no content)
git svn init -s https://svn.isy.liu.se/rt/tidefelt/source/shapes shapes
cd shapes
git svn fetch  # No files present in any commit
cat .git/config
[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
[svn-remote "svn"]
        url = https://svn.isy.liu.se/rt
        fetch = tidefelt/source/shapes/trunk:refs/remotes/trunk
        branches = tidefelt/source/shapes/branches/*:refs/remotes/*
        tags = tidefelt/source/shapes/tags/*:refs/remotes/tags/*

What seems to complicate things here, and that I didn't realize
before, is that I have access to https://svn.isy.liu.se/rt (at least
read), so if git-svn starts from the bottom and checks for premissions
it will find this root directory.

WITH CHANGED STANDARD LAYOUT (retrieves neither content nor tags)
git svn init -s https://svn.isy.liu.se/rt/tidefelt/source/shapes shapes.fix
cd shapes.fix
# Edit .git/config
git svn fetch
cat .git/config
[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
[svn-remote "svn"]
        url = https://svn.isy.liu.se/rt/tidefelt/source/shapes
        fetch = trunk:refs/remotes/trunk
        branches = branches/*:refs/remotes/*
        tags = tags/*:refs/remotes/tags/*

The version where I make changes in .git/config file fails also for a
project that I don't have any problems with just using the -s option.
Do I have to do anything more than just change the config file?

All of the above git svn fetch complains a bit the first time with a
message similar to:

W: Ignoring error from SVN, path probably does not exist: (175007):
HTTP Path Not Found: REPORT request failed on
'/rt/!svn/bc/100/tidefelt/source/shapes':
'/rt/!svn/bc/100/tidefelt/source/shapes' path not found

Please, let me know if there is any other information that would be useful.

/Gustaf

      reply	other threads:[~2007-11-29 10:00 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-22 13:37 git-svn: surprising behaviors/bugs? Gustaf Hendeby
2007-11-29  8:10 ` Eric Wong
2007-11-29  9:59   ` Gustaf Hendeby [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bf7b2dda0711290159v49b5bc2elb072b610d2237755@mail.gmail.com \
    --to=hendeby@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=normalperson@yhbt.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).