mercurial to fossil conversion: how to enforce canonical name for "trunk"
(1) By jvdh (veedeehjay) on 2023-05-10 09:49:58 [link] [source]
I have some old mercurial repo which I finally want to migrate to fossil. I would prefer standard fossil naming convention for the "trunk" branch (a.k.a. "master" in git .a.ka. "default" in hg). I did
hg fastexport > fe.txt
and then tried all of the below:
fossil import --git fsl.repo fe.txt fossil import --git --rename-master trunk fsl.repo fe.txt fossil import --git --rename-trunk trunk fsl.repo fe.txt
which all produced a fossil repo where trunk is named "default" (i.e. uses the mercurial convention) and also carries a standard tag named "trunk" -- which is not what I want. the
--rename-X seemingly are having no effect at all...
question: what would be the recommended way to get standard fossil naming (trunk branch called "trunk" and no other tags attached by default)?
(2) By Stephan Beal (stephan) on 2023-05-10 09:57:47 in reply to 1 [link] [source]
what would be the recommended way to get standard fossil naming (trunk branch called "trunk" and no other tags attached by default)?
Perhaps simplest is to manually rename it after importing. Run "fossil ui", visit the timeline, find the first check-in, and edit it with the "make this the start of branch X" feature, with X=trunk.
(3) By jvdh (veedeehjay) on 2023-05-10 10:18:57 in reply to 2 [link] [source]
thanks! that was too easy and too obvious ;). or rather: in fact, I did not try this because I expected this just would create another branch named "trunk" besides "default" starting at first checkin...
so I do not really understand why this works: why does no spurious "default" branch remain after the "make first check-in start of (new?) branch trunk"?
(4.1) By Andy Bradford (andybradford) on 2023-05-10 14:27:06 edited from 4.0 in reply to 3 [link] [source]
> why does no spurious "default" branch remain after the "make first > check-in start of (new?) branch trunk"? This is because in Fossil, a "branch" is just a tag that propagates to all descendents until canceled. Andy
(6) By jvdh (veedeehjay) on 2023-05-10 18:20:10 in reply to 4.1 [link] [source]
that much -- branches identified by propagating tags -- I am actually aware off :P. my difficulty was (still is ...) that I interpret
"Make this check-in the start of a new branch named X"
in the GUI edit option for a checkin as creating a new branch branching off from the specified checkin. or is this a misconception?
at least in the present case (when doing this on first checkin of the repo) it seems to actually enact a rename from (in this specific case) "default" to "trunk" as the branch name.
I also do not quite understand what happens exactly during the
fossil import: as said all checkins carried two tags: 1. "default", 2. "trunk", where "default" was the actual branch name. so what is the "trunk" tag doing there at all?
but anyway, repo now looks good after all :).
(9) By Stephan Beal (stephan) on 2023-05-10 18:35:03 in reply to 6 [link] [source]
... in the GUI edit option for a checkin as creating a new branch branching off from the specified checkin. or is this a misconception?
It's not a new branch in the sense that it's branching off from the original while keeping the original intact. It's new in the sense that that line of the tree is being assigned a new symbolic name starting at the given checkin. We could possibly relabel that as "rename branch to..." but whether or not that would be semantically correct, vis a vis the internals, is up for debate.
... so what is the "trunk" tag doing there at all?
That one's above my proverbial pay grade ;).
(10) By Andy Bradford (andybradford) on 2023-05-10 18:43:51 in reply to 6 [link] [source]
> "Make this check-in the start of a new branch named X" I see what you mean. It depends on context. If you take the root of a "branch" and apply the propagating tag there, the entire branch is "renamed". If you take the leaf of a "branch" and apply the propagating tag there only that leaf is "renamed" (and it looks like a new branch was created), the timeline will now show it branching off and departing from the original "branch". I'm not sure if there is a better way to convey both meanings in a single checkbox. In neither case does a new "commit" happen, just a control artifact generated that amends the name of the "branch". Perhaps better text would be: "Starting with this commit, rename the branch to X" Though this seems more of a case of "learned behavior". Thoughts? Andy
(12) By Stephan Beal (stephan) on 2023-05-10 18:59:19 in reply to 10 [source]
"Starting with this commit, rename the branch to X"
Though this seems more of a case of "learned behavior". Thoughts?
The origin of the confusion is, in hindsight, obvious and it now seems odd that this confusion hasn't (AFAIR) come up before. Changing the label to specifically indicate a "rename" instead of implying creation of a new branch seems sensible to me. FWIW.
(5) By Stephan Beal (stephan) on 2023-05-10 16:22:37 in reply to 2 [link] [source]
Perhaps simplest is to manually rename it after importing.
Now that i'm back on a keyboard, there's a simpler way to do it. From a checkout:
$ fossil amend --branch trunk root:tip
should do the trick for most repositories. In some (like fossil's own), the "root" may resolve to somewhere other than the first checkin. In place of "root:tip" you can also use the hash of the first checkin.
Unfortunately, i can't answer the underlying question of why the import options don't rename the branch for you. git import/export is, quite fortunately, something i've never needed to touch.
(8) By jvdh (veedeehjay) on 2023-05-10 18:27:51 in reply to 5 [link] [source]
thanks! I will make a screenshot of this and try it out in due time;).
you are also right in that the actual question indeed is why the rename does not happen during import. maybe fossil only recognizes the git default name ("master") but does not do sof for hg which calls trunk "default"? it's no big deal but of course minimally annoying that one has to intervene manually after the import along the lines you suggested in order to restore a "sane" branch name.
regarding fastexport, I am just happy that hg did provide/support this option and that fossil import can read it. principally it's a nice and easy way to migrate a repo from hg (or git, naturally) to fossil (or the other way around I think?). which is nice.
(7) By MBL (RoboManni) on 2023-05-10 18:26:59 in reply to 1 [link] [source]
I am a beginner with mercurial but feel confident with fossil (and using it every day a lot already for many years).
Now I got a big folder with a mercurial repository and wonder how to convert it into a fossil repository. Your post was my trigger.
I am running on Windows, so I installed the
TortoiseHG 6.4.2 MSI installer - x64 Windows 10+.
After looking for some hg help I was able to find the info how to enable the
Then I tried your approach; but in my case it seems not to be as simple as in yours.
D:\project\hg-pro>C:\UserPrograms\Mercurial\hg.exe fastexport>fe.txt abort: Unable to parse user into person and email for revision >3968867b36b16523ccbfde4519c5d674cec33f2b D:\project\fsl-pro>fossil.exe import --git proj.fossil ../hg-pro/fe.txt Rebuilding repository meta-data... 100.0% complete... Vacuuming... ok project-id: 0195cd9da20fb8ec7bad4a31dd4c99922dbb00cd server-id: c4705cd3cbb2e9480dc4cbd14d592d57c3e8815d admin-user: XXXXXX (password is "YYYYYYYYYY")
The result is an initial checkin with "all" the files of the project init but not the whole history.
Can you give me a hint how to overcome the errors, please?
(11) By jvdh (veedeehjay) on 2023-05-10 18:46:00 in reply to 7 [link] [source]
sorry, no idea. I am not a mercurial expert either. but it seems the problem indeed happens during the `hg fastexport' so that you might look for help on the mercurial mailing list?
(13) By MBL (RoboManni) on 2023-05-11 07:29:29 in reply to 11 [link] [source]
I searched for help and got the new chat-bot of Bing, which helped me with its 5 questions-per-day limit to find locations and format of the username, which is just
firstname lastname <firstname.lastname@example.org>
What I found is that my trouble-causing change-set (and maybe more later on) has a
user but is set with double-quotes, which is the unexpected format that aborted my trial. The preferred username can be set with the hg workbench (thgw.exe) ->File ->Settings ->Commit ->Username or ->EditFile, it is without any quotes or double-quotes.
I think once I would find a way how to re-assign the user name into the repository contained history change-sets or how to ignore its parsing then the command
hg fastexport would (probably and hopefully) succeed.
Sorry for noising this thread. The way "how to" is now clear to me and my findings so far will be of some help as well for someone.
(14.1) By MBL (RoboManni) on 2023-05-14 11:04:23 edited from 14.0 in reply to 13 [link] [source]
I succeeded by doing the following steps:
- searching all the format disturbed user entries, there were just 2 in my case, which were used multiple times
- creating the file
authors.convert.listwith a "from disturbed" to "well formatted" list
- enabling in the thgw.exe the extension
- calling command line:
hg convert --authors authors.convert.list mercurial-repo-dir
It took a long time in my case to convert the whole repositiory into a corrected new one. But from that new converted report it was as described above an easy step to do the
hg fastexport and the
fossil import --git . It took its time but it worked.
- original mercurial repository (.hg folder): 202 MB file sizes, 288 MB on data medium
- new mercurial repository (.hg folder of the converted original): 132 MB file sizes, 217 MB on data medium
- fastexport'ed text file format from mercurial repository: 2.53 GB
- localhost:8080/stat :
- file size: 166 MB after import from text file
- Compression Ratio 96:1
- Number of check-ins: 10663
- Number of files: 26746
- Duration of project: 2924 days or approximately 8.01 years
- Database stats: 42401 pages, 4096 bytes/page, 0 free pages, UTF-8, delete mode
fossil rebuild --wal --compress:
- file size: 165 MB
- Compression Ratio 97:1
- Repository rebuilt: By Fossil 2.21 [f9aa474081]
- Database stats: 42188 pages, 4096 bytes/page, 0 free pages, UTF-8, wal mode
Thanks again for all the inspiration and hints.
EDIT: Duration of project correction by using
fossil amend --date on two wrongly dated check-in's