Working on the `lnk clone` patch I noticed the following.

This test passes

    cargo nextest run default_branch_head

But this fails

    cargo nextest run -p librad-test default_branch_head

I haven't figured out why yet. What I am worried is happening is that
the `replication-v3` feature flag is getting turned on by some part of
the top level test crate and that we are consequently not testing
non-replication-v3 in CI. Anyone have any insight?

> Anyone have any insight?

- stabilise replication-v3
- refrain from using feature flags
- use a sane build tool

On 30/05/22 01:07pm, Kim Altintop wrote:
> - stabilise replication-v3

I think we should do this. The problem here is caused by the fact that
`gitd-lib` and `lnk-sync` depend non-optionally on replication-v3, which
brings the feature in for the whole create so `cargo test` always runs
with replication-v3. This means we have two options:

1. Add implementations of the missing parts of `gitd-lib` and `lnk-sync`
   for non-replication-v3 and make the replication-v3 dependency optional
2. Stabilise replication-v3

Replication v3 is now feature complete and in practice, no one is
depending on replication-v2 (or whatever it is) _at all_ as most of the
rest of the ecosystem is using the alt-clients git push/pull based
replication. Consequently I think the risk of stabilising is very low.

On Mon May 30, 2022 at 12:49 PM IST, Alex Good wrote:
> On 30/05/22 01:07pm, Kim Altintop wrote:
> > - stabilise replication-v3
>
> I think we should do this. The problem here is caused by the fact that
> `gitd-lib` and `lnk-sync` depend non-optionally on replication-v3, which
> brings the feature in for the whole create so `cargo test` always runs
> with replication-v3. This means we have two options:
>
> 1. Add implementations of the missing parts of `gitd-lib` and `lnk-sync`
>    for non-replication-v3 and make the replication-v3 dependency optional
> 2. Stabilise replication-v3
>
> Replication v3 is now feature complete and in practice, no one is
> depending on replication-v2 (or whatever it is) _at all_ as most of the
> rest of the ecosystem is using the alt-clients git push/pull based
> replication. Consequently I think the risk of stabilising is very low.

Ya, let's do it. I initialy held off because of removing gitoxide, but
that's a whole 'nother kettle of fish.

This will make our lives easier :)

On Mon May 30, 2022 at 12:49 PM IST, Alex Good wrote:
> On 30/05/22 01:07pm, Kim Altintop wrote:
> > - stabilise replication-v3
>
> I think we should do this. The problem here is caused by the fact that
> `gitd-lib` and `lnk-sync` depend non-optionally on replication-v3, which
> brings the feature in for the whole create so `cargo test` always runs
> with replication-v3. This means we have two options:
>
> 1. Add implementations of the missing parts of `gitd-lib` and `lnk-sync`
>    for non-replication-v3 and make the replication-v3 dependency optional
> 2. Stabilise replication-v3
>
> Replication v3 is now feature complete and in practice, no one is
> depending on replication-v2 (or whatever it is) _at all_ as most of the
> rest of the ecosystem is using the alt-clients git push/pull based
> replication. Consequently I think the risk of stabilising is very low.

Can confirm that both incantations works on `seen` with the stable
replication-v3 changes :)