I’m using SubGit locally, and we have some branches that are under a subfolders. i.e. /branches/Folder/Branch
The default branch conversion then causes the git branch to be Folder, and Branch a folder within the branch itself.
I could manually map the branches in the config file so that the git branch will be Folder/Branch, however that will cause the history from deleted branches to not be a part of the migration.
From what I read in the documentation, it then seems like I would have to find all the deleted branches and map them.
Is this what I have to do or am I missing something? Unfortunately ‘–layout auto’ doesn’t work with local. I do want to try it remote and see what it comes up with for the config file, but it looks like I have to arrange to make some changes to httpd.conf on the subversion server after hours first.
you are right, SubGit does not perform the same actions in local mode as it’s doing in the remote mode with “layout auto” and I’m afraid the only way to get the history of removed branches in local mode is what you already mentioned – add the mapping for those branches manually. So the remote mode seems to be more appropriate for that setup, indeed.
Yet I don’t think you would need to change the httpd.conf in any way, it is possible to establish a remote mirror using the file protocol instead. So, if, fo example. you repository (or, more precisely, a project in a repository) resides in /svn, then it can go this way:
Thanks Ildar,
The httpd.conf change was because the svn client is getting ‘Request entity too large’ when I ran subgit configure.
I see that the autogenerated conf file does include deleted branches, but it looks like it only include branches that were full copies of trunk.
In the configure log, I see things like:
pattern ‘/branches/BranchParent/*’ dissected: maps more non-branches (172), than branches (2)
Now, I know I have to fix these branches up afterwards, and I already have a script in order fix them up and graft them back to the trunk.
It looks like I would have to figure out for myself all the deleted branches in SVN and manually add them to the conf, however maybe that wouldn’t get me any farther ahead? If I add them manually, I assume they won’t be contributing to trunk history anyway?
I’m not sure if I understand you question and setup correctly, you are asking whether adding a mapping for a previously deleted branch would add its history in Git, right? If so, then answer is “yes”, adding such a mapping will add the branch history to Git repository – in fact, this is the right way to get history of old removed branches in the target Git repository.
SubGit relies upon certain adding/removing patterns trying to find branches, so if a branch was created not by copying some other, then it may be overlooked, indeed. This scanning/autogenerating is not 100% reliable, some manual configuration is usually required, indeed.
Thanks Ildar,
So far what I’ve seen with my test conversions is that if a branch was not a full copy of trunk, there are no links back to trunk on that branch in Git. Thus why I’ve created a script to do some grafting. I’ll do a new conversion with all branches mapped appropriately and see what it looks like.
java.lang.IndexOutOfBoundsException
at java.nio.Buffer.checkIndex(Unknown Source)
at java.nio.HeapByteBuffer.get(Unknown Source)
at org.tmatesoft.svn.core.internal.io.fs.FSRepositoryUtil.loadRootChangesOffset(FSRepositoryUtil.java:303)
at org.tmatesoft.svn.core.internal.io.fs.FSRevisionRoot.loadOffsets(FSRevisionRoot.java:222)
at org.tmatesoft.svn.core.internal.io.fs.FSRevisionRoot.getChangedPaths(FSRevisionRoot.java:50)
at org.tmatesoft.svn.core.internal.io.fs.FSRoot.detectChanged(FSRoot.java:293)
at org.tmatesoft.svn.core.internal.io.fs.FSLog.fillLogEntry(FSLog.java:343)
at org.tmatesoft.svn.core.internal.io.fs.FSLog.sendLog(FSLog.java:290)
at org.tmatesoft.svn.core.internal.io.fs.FSLog.runLog(FSLog.java:162)
at org.tmatesoft.svn.core.internal.io.fs.FSRepository.logImpl(FSRepository.java:383)
at org.tmatesoft.svn.core.io.SVNRepository.log(SVNRepository.java:1041)
at org.tmatesoft.svn.core.io.SVNRepository.log(SVNRepository.java:946)
at com.syntevo.svngitkit.core.internal.g.e.c(SourceFile:85)
at com.syntevo.svngitkit.core.internal.g.e.a(SourceFile:35)
at com.syntevo.svngitkit.core.internal.g.e.a(SourceFile:28)
at com.syntevo.svngitkit.core.internal.g.h.f(SourceFile:121)
at com.syntevo.svngitkit.core.internal.g.h.d(SourceFile:106)
at com.syntevo.svngitkit.core.internal.g.h.a(SourceFile:85)
at com.syntevo.svngitkit.core.internal.g.c.a(SourceFile:70)
at com.syntevo.svngitkit.core.internal.g.d.a(SourceFile:24)
at com.syntevo.svngitkit.core.c.C.a(SourceFile:933)
at com.syntevo.svngitkit.core.c.C.b(SourceFile:661)
at com.syntevo.svngitkit.core.c.C.a(SourceFile:436)
at com.syntevo.svngitkit.core.c.C.a(SourceFile:396)
at com.syntevo.svngitkit.core.c.C.a(SourceFile:342)
at com.syntevo.svngitkit.core.c.C.a(SourceFile:169)
at com.syntevo.svngitkit.core.c.O.c(SourceFile:43)
at com.syntevo.svngitkit.core.c.O.b(SourceFile:36)
at org.tmatesoft.translator.k.aj.a(SourceFile:1464)
at org.tmatesoft.translator.k.aj.c(SourceFile:997)
at org.tmatesoft.translator.k.aj.a(SourceFile:1020)
at org.tmatesoft.translator.k.aj.b(SourceFile:1078)
at org.tmatesoft.translator.k.aj.a(SourceFile:682)
at org.tmatesoft.translator.k.aj.a(SourceFile:651)
at org.tmatesoft.translator.k.c.g.a(SourceFile:231)
at org.tmatesoft.translator.k.c.g.d(SourceFile:133)
at org.tmatesoft.translator.a.N.b(SourceFile:55)
at org.tmatesoft.translator.a.t.c(SourceFile:23)
at org.tmatesoft.translator.b.a(SourceFile:193)
at org.tmatesoft.translator.b.a(SourceFile:144)
at org.tmatesoft.translator.b.a(SourceFile:54)
at org.tmatesoft.translator.process.f.d(SourceFile:136)
at org.tmatesoft.translator.process.f.c(SourceFile:106)
at org.tmatesoft.translator.b.a(SourceFile:79)
at org.tmatesoft.translator.b.a(SourceFile:70)
at org.tmatesoft.translator.SubGit.main(SourceFile:10)