Re: git-svn: surprising behaviors/bugs?

From: Eric Wong <normalperson@yhbt.net>
Date: Nov 29, 2007, 08:10 UTC
Message-ID: <20071129081031.GF32277@soma>
In-Reply-To: <bf7b2dda0711220537h3f37c84ag899b74daa9a8fe1f@mail.gmail.com>

Gustaf Hendeby <hendeby@gmail.com> wrote:

Show 20 quoted lines

> I've been running git for most my stuff for some time now, and am
> really pleased with what it has to offer.  However, all my coworkers
> aren't gitified yet, and therefore I sometimes have to work with svn.
> I've learned to appreciate git-svn for this, since it lets me utilize
> the strengths of git and still allows for my coworkers to think I use
> their svn setup.  Thanks to all who contribute to this wonderful
> tools!
> 
> In my work with git-svn I have stumbled upon the following two
> unexpected behaviors.  Basically, am I doing/understanding something
> wrong, or is this buggy behavior in git-svn?  (I'm presently using git
> 1.5.3.6, but have been experiencing these things for a while.)
> 
> 
> 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.

Show 11 quoted lines

> 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?

Show 7 quoted lines

> 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.

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

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?

Thanks,

-- 
Eric Wong