In a previous post, I asked about splitting a repository and was informed there wasn't a built-in command to do it. I was also advised to look into reposurgeon, to see if might provide a way to do it. I did check reposurgeon, but it will only split at a given check-in, it won't split based on directories. So now I'm getting ready to split the repository manually.

I'd like to reconstruct many of the existing branches and tags. Does anyone have any advice to offer on the best way to reproduce them? For branches, I guess that means determining which check-in originated the branch and recreating it at that change in the parent branch (which must also be determined). Tags seem more straightforward, though I'd want to make sure I recreate them in the correct branch.

Thanks, mike

it will only split at a given check-in

Nonsense. If reposurgeon allows keeping the history of a single file, you can certainly use it to keep the history of a single directory. Delete all paths you don't want to keep to keep them from appearing in the output.

There's an example of this in the program's Quick Start: 1..$ delete path /documents/.*.pdf/

Warren,

Thank you for the reply. When I last looked into this, I saw there was an explicit 'reposurgeon split' command and when I determined it did not do what I needed, I did not investigate further. I will do so now, with your advice.

However, I do have concerns about reposurgeon in general. I believe it uses the fossil git import/export feature to work its magic. When I first transitioned my git repository to fossil, I encountered problems that had lasting effects, so I'm a bit hesitant to use that feature again.

Maybe it won't be a continuing problem any, now that I've moved past the co-mingled branches problem. I will be going from fossil into reposurgeon (via git format) this time, instead of git into fossil. That might be a smoother transition. Still, if anyone has advice on how I could do the split manually, I'd be interested in hearing it, as an alternative.

mike

Hi hanche, Looking at vcs.go in the reposurgeon source, I find the following:

                {
                        // Styleflags may need tweaking for round-tripping
                        name:         "fossil",
                        subdirectory: "", // There's a special case in manages()
                        requires:     newStringSet("fossil"),
                        exporter:     "fossil export --git",
                        quieter:      "",
                        styleflags:   newOrderedStringSet(),
                        extensions:   newOrderedStringSet(),
                        initializer:  "fossil init .fossil && fossil open .fossil",
                        pathlister:   "", // fossil extras is the inverse of this
                        taglister:    "fossil tag list",
                        branchlister: "fossil branch list", // Should we list with --all? Unclear...
                        importer:     "fossil import --git",
                        checkout:     "",
                        viewer:       "", // fossil ui looks tempting but has no clean exit.
                        prenuke:      newOrderedStringSet(),
                        preserve:     newOrderedStringSet(),
                        authormap:    "",
                        ignorename:   ".fossil-settings/ignore-glob",
                        dfltignores:  "", // ignore-glob is empty by default
                        cookies:      nil,
                        project:      "https://fossil-scm.org/",
                        notes:        "",
                        idformat:     "%s",
                        flags:        ignGLOB | ignQUES | ignCARET | ignESC | ignGSTAR,
                },

It looks to me like it interfaces with fossil via fossil's git import/export feature. That's what I meant. I did not mean that it creates an intermediate git repository.

As I mentioned on one of my other posts I linked to, there appears to be a case where fossil will dereference a null pointer when doing a git import/export. I have no knowledge of the git exchange format, so I wasn't able to track down the problem any further. I don't know what was in my git repository that triggered the bug, but it has made me a bit leery of using reposurgeon since it appears to use the same git import/export feature.

Here's what I said in the linked post. That post is a couple years old now, so it might not be true any more:

Taking a quick look at import.c and export.c, I see a potential problem. export_mark() in export.c calls mark_name_from_rid() to retrieve a mark before writing it out. It does not check that return value against NULL before using it.

The comment for mark_name_from_rid() says NULL is returned if the rid does not have an associated UUID (i.e. is not valid). Determining why that might be the case is a bit beyond me.

mike

Okay, new plan: fossil deconstruct your repo, then throw grep/sed/awk/perl/holy-hand-grenade… at the manifests until thine foes be vanquished. Reconstruct it from the battle debris and pray to $DEITY that it comes back together properly.

Thanks Warren,

I will investigate fossil deconstruct, too.

mike

To follow-up, I gave reposurgeon a try, but it panics and crashes trying to read the repository. Whatever problem was introduced when I first imported the git repository must still be present.

With the reposurgeon option eliminated, I'll need to do it the hard way. I think I'll start with a new, empty repository and re-introduce key events from the original repository (omitting anythings from the directories I want to exclude). I'll use the root: and start: tag modifiers to reproduce the start of branches. I'll grep the output of fossil timeline for MERGE to locate when merges occurred. Reproducing tags should be straight-forward.

I haven't decided yet if I want to try to reproduce every individual check-in. I might just aim for the key events mentioned above. I suppose it depends on how much I can automate and how much I need to do manually.

Hi Andy, Thanks. That will be useful.

The fossil timeline command can output a phase value. I can't find where this is documented. It looks like interesting events like tagging and branching happen in check-ins with phase LEAF. But there are also MERGE and BRANCH phases. I'm wondering if I can streamline things by only looking at check-in artifacts with these phases. Is this a valid approach (if I'm not trying to capture every individual file change), or do need to inspect everything?