Tue, Sep 17
Mon, Sep 16
Sat, Sep 14
Fri, Sep 13
I showed in D6847 the same change but implemented in exchange._processcompared. Tests pass.
I think it'd make for a simpler final state: with the current change, the client sees that the bookmark is going to move sideways, decides this is fine, requests that the server validates that the bookmark is indeed moving sideways (which it does), but in the end the server rejects the move. In the suggested change, the client sees that the bookmark is going sideways and rejects it. This should be consistent with the way new heads or new branches or diverging rewrites are prevented.
Thu, Sep 12
Wed, Sep 11
We're really close. I've uploaded my rebase of this to the latest dev hg (along with some minor test fixes). There's now only one failure:
Neat. I assume you normally check these out later?
This looks good to me. Does anyone else have comments? @mharbison72 are you happy with the subrepo test coverage?
I'm okay with this as-is. Barring an objection in a week or so I'll queue it.
I've uploaded my revised version (with the more complete commit message - no other changes) in case that helps.
I get a fair number of test failures with this, eg test-bookmarks-corner-case.t:
Queued this with lots of content added to the commit message. Thanks!
- In lfs, where we deal with standins and mutating status.
Tue, Sep 10
Mon, Sep 9
FWIW I'm +0.5 on this because it seems like a reasonable abstraction and could serve a variety of purposes.
This is a start, but I suspect where we should end up with this is downloading and compiling the whole Python distribution, rather than relying on a virtualenv to be portable?
Clarifying I understand: this causes pushing a bookmark to fail in what cases that it currently succeeds? I think it's just the case of:
I like where this is going, but I wonder if these specific hooks can be written without being in-process Python hooks. Reason being that Python hooks use the unstable internals of hg and are semi-discouraged if they're avoidable.
I went through the history of this line and sadly it came into existence with the initial check-code.py commit. However, I got to use hg grep for the purpose nobody uses (!) and found this:
Thu, Sep 5
Ping on this - can we get this landed to unblock my experimentation?
Fri, Aug 23
Thu, Aug 22
I think pushing it down into the store makes a reasonable amount of sense, since it's going to be pretty heavily tied to the revision storage mechanism...
Folded this and D6748 back into 6734, many thanks!
Aug 20 2019
I was trying to understand current interfaces and write new ones and I realized
we need to improve how current interfaces are organised.
And what was the reason we need to improve it? I assume we don't really "need" to change it. Will it somehow help with future patches? Or you just like this structure better?
Looking through Augie's hgit patch, I found we need to add more interfaces and decided to work on adding for store.basicstore. I found all the current interfaces in repository.py which has grown very large. I decided to create a new file to have interface for the store class, and maybe a new one for dirstate too, and having them in a separate folder dedicated to interfaces will be nice.
Aug 17 2019
Aug 16 2019
Aug 15 2019
Looks good to me, but I want someone else to put eyes on it before it gets pushed.
The only thing I'm curious about really is why we have extrastorage and usualstorge. Can we get away with only one of those choices instead of having more options?
Aug 14 2019
I'm not thrilled with this - it's a lot of code, and I think there are some simpler options that haven't been explored. For example, clients could use the logexchange infrastructure to prime the sampling process and do a lot better.