git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git-svn-Cloning repository with complicate nesting

From
DSDaniele Segato <daniele.bilug@gmail.com>
Date
Sep 3, 2009, 16:17 UTC
Message-ID
<9accb4400909030917y2e8d4c97tef1320c05d4c4e1c@mail.gmail.com>
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

Previous: Marc BranchaudNext: Marc Branchaud
Message 3 of 4 in “git-svn-Cloning repository with complicate nesting”
  1. Daniele SegatoAug 27, 2009
  2. Marc BranchaudSep 3, 2009
  3. Daniele SegatoSep 3, 2009
  4. Marc BranchaudSep 3, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.