From: Daniele Segato <daniele.bilug@gmail.com>
To: Marc Branchaud <marcnarc@xiplink.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: git-svn-Cloning repository with complicate nesting
Date: Thu, 3 Sep 2009 18:17:07 +0200 [thread overview]
Message-ID: <9accb4400909030917y2e8d4c97tef1320c05d4c4e1c@mail.gmail.com> (raw)
In-Reply-To: <4A9FD34A.7020101@xiplink.com>
On Thu, Sep 3, 2009 at 4:31 PM, Marc Branchaud<marcnarc@xiplink.com> wrote:
> Hi Daniele,
Hi Marc and thank you for your reply.
> I think you're stuck. Someone who knows git-svn better than I might be able to figure out a solution (I haven't played with using wildcards in the middle of branches refspecs), but as far as I can tell git-svn can't support your repository's structure.
>
> The fundamental problem is that the BRANCHES/ hierarchy isn't consistent. git-svn expects the directories under a 'branches' path to be branch names. In your case, you can't specify a configuration that covers your whole repository.
yes..
and developers should be smart enought to keep consistency on their
own.. unfurtunately they oftern aren't
> So I think git-svn would need to be modified to support your situation.
I'm not feeling that lucky but I would be happy about it. :-)
> One possible approach is to make git-svn smart about what it considers a branch's name. In theory, what you'd like is to just specify
> To do this, git-svn could track the current 'trunk' directory structure (just the top-level contents of the root should suffice). Then when it detects a new path under BRANCHES it could search through that path until it finds the same 'trunk' directory structure, and then use the path as the full branch name.
> When a commit creates a new branch:
> git-svn sees that the commit is to a new path under branches/ and looks through branches/some/ and branches/some/path/ to find the trunk's contents, deciding in this case that 'some/path' is the branch's name.
>
> Anyway, this is just an idea of how things might work. There are probably some corner-cases that could make this a bit tricky to implement...
hum...
It could be an idea but I don't know how hard could it be to check it:
how much deep inside the tree should Git search for branch? what if
there are branches that are completely differents?
may be the user could create and pass a "branch model" to git svn to
make it able to decide what is a branch and what isn't.
I think there are many options
In my case It would have worked defining a structure like:
BRANCHES/*/root -> remote/svn/branch/*
BRANCHES/*/*/root -> remote/svn/branch/*/*
But it would be better with something like:
BRANCHES/\([^\/]+\)/root -> remote/svn/branch/$1
BRANCHES/\([^\/]+\)/\([^\/]+\)/root -> remote/svn/branch/$1/$2
like a grouped regex.
every branch not matching the regex will be skipped..
only an idea.. It couln't work in every situation but it would allow a
greater degree of freedom in the configuration.
I don't know if Git developers are interested in thinking on some
features like this.. it sound like an SVN-only hack to me.
Regards,
Daniele
next prev parent reply other threads:[~2009-09-03 16:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-27 8:32 git-svn-Cloning repository with complicate nesting Daniele Segato
2009-09-03 14:31 ` Marc Branchaud
2009-09-03 16:17 ` Daniele Segato [this message]
2009-09-03 16:50 ` Marc Branchaud
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=9accb4400909030917y2e8d4c97tef1320c05d4c4e1c@mail.gmail.com \
--to=daniele.bilug@gmail.com \
--cc=git@vger.kernel.org \
--cc=marcnarc@xiplink.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.
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).