From: Eric Wong <normalperson@yhbt.net>
To: Russ Brown <pickscrape@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: git-svn and a nested branches folder
Date: Tue, 4 Sep 2007 17:15:13 -0700 [thread overview]
Message-ID: <20070905001513.GA9362@soma> (raw)
In-Reply-To: <46DD6EEA.9010304@gmail.com>
Russ Brown <pickscrape@gmail.com> wrote:
> Hi,
Hi Russ,
> I'm having some trouble with using git-svn to fetch a repository, and I
> think it's because the repository doesn't store branches as a flat list
> directly under the 'branches' directory.
>
> Basically, we have a structure like this:
>
> |
> +-trunk
> +-tags
> +-branches
> + category-a
> + branch-a
> + branch-b
> + category-b
> + branch-c
> + branch-d
>
> etc. category-a and category-b are simple directories created using svn
> mkdir. The branches are created using svn cp.
>
> It helps us to organise the branches better, but the rationale is
> besides the point. The problem is that git-svn seems to want to treat
> category-a and category-b as branches, which isn't right at all. As a
> result, git-svn seems to skip most (if not all) revisions that occur in
> these directories and creates a lot of entries in unhandled.log.
This is a known problem with the way git-svn handles branches and tags.
Nested branch (and tags) structures aren't supported with globbing and
so you can't have more than one branches/tags specification in your
config.
> I've also encountered an index corruption in one of the
> .git/svn/<branch>/index files which I think it probably related.
Not sure about that. git-svn should detect and attempt to fix index
corruptions (which happened for me since I interrupt git-svn quite
often when working on it).
> I've had a quick look at the source myself, but perl isn't my strong
> point. What I think it should do is something like recurse down the tree
> from the directory given looking for folders that copy from trunk (or
> some other branch that already exists). That would work perfectly well
> for the default flat branch storage method as well as the one we use.
The globbing functionality of branches in git-svn is some of the ugliest
code I've ever written in my life. Somehow I got it working for the
simple general cases but I've been afraid to touch it for a while...
> The only other problem is in branch naming, which could clash if you
> only use the outer-most directory name, so I'd suggest something that
> involves concatenating the folders in the path relative to 'branches' to
> keep them unique (if git can handle slashes in branch names then all the
> better).
As Peter suggested, disable globbing for branches and use explicit
fetch refspecs for now...
--
Eric Wong
next prev parent reply other threads:[~2007-09-05 0:15 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-04 14:42 git-svn and a nested branches folder Russ Brown
2007-09-04 14:46 ` David Kastrup
2007-09-04 14:54 ` Russ Brown
2007-09-04 15:01 ` David Kastrup
2007-09-04 15:21 ` Russ Brown
2007-09-04 17:40 ` Peter Baumann
2007-09-04 18:03 ` Russ Brown
2007-09-05 0:15 ` Eric Wong [this message]
2007-09-05 9:56 ` Russ Brown
2007-09-05 10:09 ` Eric Wong
2007-09-05 10:15 ` Russ Brown
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070905001513.GA9362@soma \
--to=normalperson@yhbt.net \
--cc=git@vger.kernel.org \
--cc=pickscrape@gmail.com \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).