excludeBranches apparently not working

145 views
Skip to first unread message

Svend Hansen

unread,
Sep 5, 2017, 7:13:10 AM9/5/17
to SubGit Users
I'm experimenting with using SubGit for converting an SVN project to git. I'd first looked a lot at using git-svn, which looked promising for the smaller test projects, but I gave up on it after several weeks running on our main project.

I'm trying to exclude a significant part of the repository by using the "excludeBranches" setting in the config file. I've added:

excludeBranches = branches/obsolete/*

where "obsolete" is the folder inside the standard "branches" location for branches containing a large number of old, no-longer-needed branches.

However, I'm seeing a lot of log messages in /<projectname>/subgit/logs/subgit-import.0.log.2 of this time:

[2017-09-05 13:04:30.088][subgit-import][1] successfully received 'branches/obsolete/<branchname>/unity/Assets/Materials/<filename>.mat.meta' with size=95

This suggests to me that the "obsolete" branches are still being included. Or are they not excluded until after they have been "received" in this way?

If this assumption is correct, is the problem the formatting of the exclude path? (should it not include the "branches/" bit?)

Or is the problem the location of the line in the config file. I've added it on the line directly after the example, in the middle of the explaining comment. However, I noticed that when it's being output it's moved to the line above this explaining comment directly after the "url" line:

url = svn://<domain>/<project-root-path>
excludeBranches = branches/obsolete/*

If the positioning is important, I guess maybe it should be placed after the "trunk", "branches", "tags" and "shelves" definitions:

trunk = trunk:refs/heads/master
branches = branches/*:refs/heads/*
tags = tags/*:refs/tags/*
shelves = shelves/*:refs/shelves/*

Like in the example of this page: https://subgit.com/import-book.html

If either of those two can be identified as the problem, would it be possible to interrupt the import, fix the config and start it again? Or would I have to start over?

Dmitry Pavlenko

unread,
Sep 5, 2017, 11:54:18 AM9/5/17
to SubGit Users
Hello Svend,
From the first glance everything you did looks correct. Indeed you can place

  excludeBranches = branches/obsolete/*

everywhere under [svn] section, so this is also correct.

I suspect that your configuration change was not applied. SubGit doesn't pick subgit/config file changes on the fly but only after running "subgit install path/to/git/repository" (in case you need continuous synchronization between SVN and Git) or "subgit import path/to/git/repository". So may I ask you to do the following:

1. Run

  subgit map branches/obsolete/branchname path/to/git/repository

OR

  subgit map svn://<domain>/<project-root-path>/branches/obsolete/branchname path/to/git/repository

"subgit map" is a hidden command, you can run "subgit help map" to see its documentation. It allows to see whether SVN path is mapped to some Git branch or not and if yes, to which one.

2. Another file I would like you to look into is

  path/to/git/repository/subgit/.run/config

When applying subgit/config configuration, SubGit copies this file (with maybe some modifications) to subgit/.run/config and only this file is actually used. So look inside it to see whether

  excludeBranches = branches/obsolete/*

is actually there.

3. The last file I would ask you to check is

  path/to/git/repository/svn/.svngit/svngitkit.config

Have a look at it and check whether it contains

    excludeBranches = branches/obsolete/*

as well.


Please share this information with us. If some of the files miss this line, with high probability (I will tell you that with higher confidence when you try steps (1)-(3)) you'll need to re-import the repository from scratch because not every option of subgit/config file can be changed and applied on the fly without re-translating the whole repository and 'excludeBranches' option is among those which need full repository re-translation, so you need to start over after changing this option.

Dmitry Pavlenko,

TMate Software,

http://subgit.com/ - git-svn bridge

Dmitry Pavlenko

unread,
Sep 5, 2017, 12:27:41 PM9/5/17
to SubGit Users
Hello Svend,
After consulting with colleagues, I now understand why the problem happens.

  excludeBranches = branches/obsolete/*

option excludes all branches matching that pattern. But as you have


    trunk = trunk:refs/heads/master
    branches = branches/*:refs/heads/*
    tags = tags/*:refs/tags/*
    shelves = shelves/*:refs/shelves/*

configuration, you have no SVN branches of form

  branches/obsolete/*

because all you branches have the following form

  branches/*


So SubGit considers

  branches/obsolete/<branchname>/unity/Assets/Materials/<filename>.mat.meta

path as

  <branchname>/unity/Assets/Materials/<filename>.mat.meta

inside 'branches/obsolete' branch, not as "unity/Assets/Materials/<filename>.mat.meta" inside "branches/obsolete/<branchname>". As result, 'excludeBranches' option does nothing because there's no branch to exclude.


So if I understand your requirements right, the following configuration will meet your needs:


    trunk = trunk:refs/heads/master
    branches = branches/*:refs/heads/*
    tags = tags/*:refs/tags/*
    shelves = shelves/*:refs/shelves/*
    excludeBranches = branches/obsolete

You can't change your current configuration on the fly, you'll need to start translation over with this configuration.

--

Dmitry Pavlenko,

TMate Software,

http://subgit.com/ - git-svn bridge



Svend Hansen

unread,
Sep 6, 2017, 2:36:25 AM9/6/17
to SubGit Users
Hello Dmitry,

Thank you so much for your replies!

I tried running the map command and what I see corroborates the theory of "branches/obsolete" being mapped as a branch, rather than the branches below:

subgit map branches/obsolete/<branchname> <path-to-git>
<path-to-git>
refs/heads/obsolete
<branchname>

So I'll make the suggested change and start over. I'm glad I discovered it after just one day. It's reached 48%, but when I left work yesterday it was at 47%, so I think it might still be quite a way off. Might need a supercomputer to do it faster ;)

Cheers,
   Svend.
Reply all
Reply to author
Forward
0 new messages