In D6776#100487, @valentin.gatienbaron wrote:

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.

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 D6837#100331, @mharbison72 wrote:

2. In lfs, where we deal with standins and mutating status.

s/lfs/largefiles/?

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:

Ping on this - can we get this landed to unblock my experimentation?

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!

In D6741#99023, @pulkit wrote:

In D6741#98947, @martinvonz wrote:

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.

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?

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.