Details
- Reviewers
Alphare - Group Reviewers
hg-reviewers - Commits
- rHG5d205e476057: rust-revlog: add methods for getting parent revs and entries
Diff Detail
- Repository
- rHG Mercurial
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Event Timeline
FYI, the functions here may seem arbitrary, but they're enough for a very simple Mercurial backend for my 20%/hobby project (see commit https://github.com/martinvonz/jj/commit/hg if you're curious). I'll add tests to this patch if you (mostly @Raphael, I suppose) think the changes look good.
I just removed the "[RFC]" without adding tests :) But I can add tests if you want. Where's a good place to add them in that case?
I think we'll want to write some basic unit tests at the end of the file. We haven't been very good about doing these in the Rust code base, but I was starting again recently with the dirstatemap (and found some bugs, of course), so that's probably a good idea.
That's actually related to another series I had not sent yet, which is about removing the &Repo input to Revlog::open(). It would be much easier to write tests if we didn't have to create a Repo instance. What do you think about taking this without tests now and then I add tests when I send that other series? Or, if you think that refactoring sounds like a good idea, I can clean that series up and insert it before this patch.
Hopefully the patches before this one can be queued without it (though there's no real rush for us yet).
By the way, Repo is not currently Send. I think the issue was with LazyCell. Do you think we should do something about that or does it not matter for your plans?
I see no issue for doing this, it's probably a good idea.
What do you think about taking this without tests now and then I add tests when I send that other series? Or, if you think that refactoring sounds like a good idea, I can clean that series up and insert it before this patch.
I prefer the option where you do the clean up first of course, but the follow-up works just as well as long as it's done.
By the way, Repo is not currently Send. I think the issue was with LazyCell. Do you think we should do something about that or does it not matter for your plans?
I'm not sure I see the value of repo being Send for now. It being Sync should probably be good enough for all of our purposes? Did you have something in mind?
I've inserted those patches in this series.
What do you think about taking this without tests now and then I add tests when I send that other series? Or, if you think that refactoring sounds like a good idea, I can clean that series up and insert it before this patch.
I prefer the option where you do the clean up first of course, but the follow-up works just as well as long as it's done.
While trying to add tests for that last night I realized that writing the test revlogs gets pretty verbose. I then found the IndexEntryBuilder in index.rs. Maybe we should move that to a common place? Maybe even out of test code so it can be used when we start writing revlogs from Rust?
By the way, Repo is not currently Send. I think the issue was with LazyCell. Do you think we should do something about that or does it not matter for your plans?
I'm not sure I see the value of repo being Send for now. It being Sync should probably be good enough for all of our purposes? Did you have something in mind?
Yes, what hg would want is Sync. The context was that I needed the hg backend to be Sync for my 20% project so I just wrapped the hg Repo in a mutex, which means that Repo needed to be Send. Anyway, if you agree that hg wants it to eventually be Sync, we'll need to address those LazyCells.
I didn't notice you had queued some patches in this series already (thanks!). I've rebased the added patches on top of @ now.
Docstring needs adjustment