development heads up: push/pull improvements

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

development heads up: push/pull improvements

Pierre-Yves David-2
Hello everyone,

I have been working on improvements to push and pull. The core goal can
be summarized as:
* make it simpler to push/pull to multiple destinations
* make it simpler to control default behavior from various destinations.

The first bits of this already landed.

* Support for multiple destinations for pull (push is in review))
   https://www.mercurial-scm.org/repo/hg-committed/rev/685383486d0a
* Support for default value for path suboption:
   https://www.mercurial-scm.org/repo/hg-committed/rev/e3f15c553522

My plan is to follow up with an handful of other improvements:

1) Make it possible for a path (in [paths] section), to reference
another one using `path://PATHNAME`, inheriting its configuration. The
inherited configuration can then be overwritten in the new path

2) Make is possible for a path to reference a list of other paths. eg:

   [paths]
   main = https://mercurial-scm.org/repo/hg
   committed = https://mercurial-scm.org/repo/hg-committed
   all = path://main, path://committed

3) add sub-options to control usage of existing flags. For example the
following config would make `--new-branch` on by default for the `devel`
path.

   [paths]
   devel = ssh://foo…
   devel:new-branch=yes

The possible values would be:

* never: the flag is never set, using --new-branch would abort the push
* no: the flag default to False, passing --new-branch enables it
* default: the default value for the flag is used
* yes: the flag default to True, passing --no-new-branch disables it
* always: the flag is always set, --no-new-branch would abort the push

4) adding more flag

They are a couple of check that does not have there own flag yet and are
only covered by `--force`. For example to push new heads. I know that
Manuel Jacob had idea about how to express these flag, so I CCed him on
this email.

This work is not my primary focus, but hope to make enough progress to
have most of it completed by the 5.8 freeze, in one month.

Cheers,

--
Pierre-Yves David
_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

Re: development heads up: push/pull improvements

Manuel Jacob
On 17/03/2021 16.05, Pierre-Yves David wrote:

> Hello everyone,
>
> I have been working on improvements to push and pull. The core goal can
> be summarized as:
> * make it simpler to push/pull to multiple destinations
> * make it simpler to control default behavior from various destinations.
>
> The first bits of this already landed.
>
> * Support for multiple destinations for pull (push is in review))
>    https://www.mercurial-scm.org/repo/hg-committed/rev/685383486d0a
> * Support for default value for path suboption:
>    https://www.mercurial-scm.org/repo/hg-committed/rev/e3f15c553522
>
> My plan is to follow up with an handful of other improvements:
>
> 1) Make it possible for a path (in [paths] section), to reference
> another one using `path://PATHNAME`, inheriting its configuration. The
> inherited configuration can then be overwritten in the new path
>
> 2) Make is possible for a path to reference a list of other paths. eg:
>
>    [paths]
>    main = https://mercurial-scm.org/repo/hg
>    committed = https://mercurial-scm.org/repo/hg-committed
>    all = path://main, path://committed
>
> 3) add sub-options to control usage of existing flags. For example the
> following config would make `--new-branch` on by default for the `devel`
> path.
>
>    [paths]
>    devel = ssh://foo…
>    devel:new-branch=yes
>
> The possible values would be:
>
> * never: the flag is never set, using --new-branch would abort the push
> * no: the flag default to False, passing --new-branch enables it
> * default: the default value for the flag is used
> * yes: the flag default to True, passing --no-new-branch disables it
> * always: the flag is always set, --no-new-branch would abort the push

I really like this feature. I don’t really see the point in "always",
but we can have it for symmetry with "never".

Speaking of defaults, it would make sense to me to allow pushing new
branches in draft phase by default, since the original point of
disallowing it was probably to prevent people from making the branch
name permanent, which isn’t a problem with draft changesets.

One nice thing would be to be able to specify the flags for all paths
matching some pattern. This may seem complicated, but doesn’t add much
more conceptual overhead in addition to the `*` special path.

For the name of the config, see the discussion below (we should use the
same names for the config and CLI flags).

> 4) adding more flag
>
> They are a couple of check that does not have there own flag yet and are
> only covered by `--force`. For example to push new heads. I know that
> Manuel Jacob had idea about how to express these flag, so I CCed him on
> this email.

The basic idea is simply to have a flag for each check to turn it off or on.

One issue is the naming, which probably requires some bideshedding. The
existing "--new-branch" never really made sense to me (it sounds as if
it always added a new branch instead of disabling some check).

Before shipping a bunch of new flags, it would be good to get it right.
Another reason for having a better naming scheme would be that a common
prefix (not every flag will start with "new") creates a bit of grouping
and aids auto-completion.

For disabling checks, prefixing it with "--allow-" makes sense to me.
The first flags to add would be:
--allow-new-branch: allow adding new branch on destination
--allow-new-head: allow increasing the number of heads on a branch on
destination

For the checks about not pushing obsolete, orphan, divergent and similar
changesets, I proposed some changes (I think the existing checks miss
problematic cases and reject legitimate ones). Pierre-Yves was concerned
about breaking expectations of users relying on the old behavior, so
this was never released. By making it possible to turn off and on
various variants of the checks, new behaviors can be designed and
developed in an incremental way. This is especially useful considering
that more advanced detection algorithms depend on accurate obsmarker
discovery, which is currently not in core.

> This work is not my primary focus, but hope to make enough progress to
> have most of it completed by the 5.8 freeze, in one month.

I won’t be able to start the “split --force” effort before the 5.8
freeze, as I‘m in the process of renovating my flat, but I’ll try to
give feedback about your efforts. Thanks for CCing me! In the next
release cycle, I will be able to spend time implementing stuff.

> Cheers,
>
_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

Re: development heads up: push/pull improvements

Pierre-Yves David-2


On 4/13/21 3:03 AM, Manuel Jacob wrote:

> On 17/03/2021 16.05, Pierre-Yves David wrote:
>> Hello everyone,
>>
>> I have been working on improvements to push and pull. The core goal
>> can be summarized as:
>> * make it simpler to push/pull to multiple destinations
>> * make it simpler to control default behavior from various destinations.
>>
>> The first bits of this already landed.
>>
>> * Support for multiple destinations for pull (push is in review))
>>    https://www.mercurial-scm.org/repo/hg-committed/rev/685383486d0a
>> * Support for default value for path suboption:
>>    https://www.mercurial-scm.org/repo/hg-committed/rev/e3f15c553522
>>
>> My plan is to follow up with an handful of other improvements:
>>
>> 1) Make it possible for a path (in [paths] section), to reference
>> another one using `path://PATHNAME`, inheriting its configuration. The
>> inherited configuration can then be overwritten in the new path

Regarding this, I have done most of the necessary work for this last
week, and I am in the process making the patches ready and sent.

The main issue is the impact on `hg path` and related templates, because
the data structure change.

I is also not possible to simply turn the [paths] entry into a "list"
field since this will break too much BC for people using " " in their path.

I am thinking about a `my-path:urls` attribute ?

>> 2) Make is possible for a path to reference a list of other paths. eg:
>>
>>    [paths]
>>    main = https://mercurial-scm.org/repo/hg
>>    committed = https://mercurial-scm.org/repo/hg-committed
>>    all = path://main, path://committed
>>
>> 3) add sub-options to control usage of existing flags. For example the
>> following config would make `--new-branch` on by default for the
>> `devel` path.
>>
>>    [paths]
>>    devel = ssh://foo…
>>    devel:new-branch=yes
>>
>> The possible values would be:
>>
>> * never: the flag is never set, using --new-branch would abort the push
>> * no: the flag default to False, passing --new-branch enables it
>> * default: the default value for the flag is used
>> * yes: the flag default to True, passing --no-new-branch disables it
>> * always: the flag is always set, --no-new-branch would abort the push
>
> I really like this feature. I don’t really see the point in "always",
> but we can have it for symmetry with "never".
>
> Speaking of defaults, it would make sense to me to allow pushing new
> branches in draft phase by default, since the original point of
> disallowing it was probably to prevent people from making the branch
> name permanent, which isn’t a problem with draft changesets.

This is still going to be an issue, because once pushed, they can easily
get "silently" published, and we don't have a check for that. Various
things the persistent branch are unfortunate, but I don't think we have
much room to improve them.

> One nice thing would be to be able to specify the flags for all paths
> matching some pattern. This may seem complicated, but doesn’t add much
> more conceptual overhead in addition to the `*` special path.

This sounds a good idea, (but I don't plan to write it myself in the
short terms)

> For the name of the config, see the discussion below (we should use the
> same names for the config and CLI flags).

+1 for using the same name

>
>> 4) adding more flag
>>
>> They are a couple of check that does not have there own flag yet and
>> are only covered by `--force`. For example to push new heads. I know
>> that Manuel Jacob had idea about how to express these flag, so I CCed
>> him on this email.
>
> The basic idea is simply to have a flag for each check to turn it off or
> on.
>
> One issue is the naming, which probably requires some bideshedding. The
> existing "--new-branch" never really made sense to me (it sounds as if
> it always added a new branch instead of disabling some check).
>
> Before shipping a bunch of new flags, it would be good to get it right.
> Another reason for having a better naming scheme would be that a common
> prefix (not every flag will start with "new") creates a bit of grouping
> and aids auto-completion.
>
> For disabling checks, prefixing it with "--allow-" makes sense to me.
> The first flags to add would be:
> --allow-new-branch: allow adding new branch on destination
> --allow-new-head: allow increasing the number of heads on a branch on
> destination

So --allow-new-branch and --no-allow-new-branch ? (or maybe
--deny-new-branch) ?

> For the checks about not pushing obsolete, orphan, divergent and similar
> changesets, I proposed some changes (I think the existing checks miss
> problematic cases and reject legitimate ones).

Do you have details on these case ?

> Pierre-Yves was concerned
> about breaking expectations of users relying on the old behavior, so
> this was never released.

Was I ? Evolution is still experimental, so reasonable behavior change
should be fine, but there might have been other issues.

> By making it possible to turn off and on
> various variants of the checks, new behaviors can be designed and
> developed in an incremental way. This is especially useful considering
> that more advanced detection algorithms depend on accurate obsmarker
> discovery, which is currently not in core.
>
>> This work is not my primary focus, but hope to make enough progress to
>> have most of it completed by the 5.8 freeze, in one month.
>
> I won’t be able to start the “split --force” effort before the 5.8
> freeze, as I‘m in the process of renovating my flat, but I’ll try to
> give feedback about your efforts. Thanks for CCing me! In the next
> release cycle, I will be able to spend time implementing stuff.

5.8 freeze is this week. So I'll focus on the "multi-path` aspect of
this work (see earlier in my original message) and we can look into the
new behavior flag for 5.9.

Cheers,

--
Pierre-Yves David
_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

Re: development heads up: push/pull improvements

Manuel Jacob
On 13/04/2021 12.16, Pierre-Yves David wrote:

> On 4/13/21 3:03 AM, Manuel Jacob wrote:
>> On 17/03/2021 16.05, Pierre-Yves David wrote:
>>> Hello everyone,
>>>
>>> I have been working on improvements to push and pull. The core goal
>>> can be summarized as:
>>> * make it simpler to push/pull to multiple destinations
>>> * make it simpler to control default behavior from various destinations.
>>>
>>> The first bits of this already landed.
>>>
>>> * Support for multiple destinations for pull (push is in review))
>>>    https://www.mercurial-scm.org/repo/hg-committed/rev/685383486d0a
>>> * Support for default value for path suboption:
>>>    https://www.mercurial-scm.org/repo/hg-committed/rev/e3f15c553522
>>>
>>> My plan is to follow up with an handful of other improvements:
>>>
>>> 1) Make it possible for a path (in [paths] section), to reference
>>> another one using `path://PATHNAME`, inheriting its configuration.
>>> The inherited configuration can then be overwritten in the new path
>
> Regarding this, I have done most of the necessary work for this last
> week, and I am in the process making the patches ready and sent.

Thank you for doing the work!

> The main issue is the impact on `hg path` and related templates, because
> the data structure change.
>
> I is also not possible to simply turn the [paths] entry into a "list"
> field since this will break too much BC for people using " " in their path.
>
> I am thinking about a `my-path:urls` attribute ?

Would the only difference to specifying the URLs in the current way that
spaces have to be escaped?

>>> 2) Make is possible for a path to reference a list of other paths. eg:
>>>
>>>    [paths]
>>>    main = https://mercurial-scm.org/repo/hg
>>>    committed = https://mercurial-scm.org/repo/hg-committed
>>>    all = path://main, path://committed
>>>
>>> 3) add sub-options to control usage of existing flags. For example
>>> the following config would make `--new-branch` on by default for the
>>> `devel` path.
>>>
>>>    [paths]
>>>    devel = ssh://foo…
>>>    devel:new-branch=yes
>>>
>>> The possible values would be:
>>>
>>> * never: the flag is never set, using --new-branch would abort the push
>>> * no: the flag default to False, passing --new-branch enables it
>>> * default: the default value for the flag is used
>>> * yes: the flag default to True, passing --no-new-branch disables it
>>> * always: the flag is always set, --no-new-branch would abort the push
>>
>> I really like this feature. I don’t really see the point in "always",
>> but we can have it for symmetry with "never".
>>
>> Speaking of defaults, it would make sense to me to allow pushing new
>> branches in draft phase by default, since the original point of
>> disallowing it was probably to prevent people from making the branch
>> name permanent, which isn’t a problem with draft changesets.
>
> This is still going to be an issue, because once pushed, they can easily
> get "silently" published, and we don't have a check for that.

I see the point. There’s stuff we could do to prevent the accidental
pushes, but it still might not be enough to allow new branches in draft
phase by default. I’m fine with leaving the current behavior.

> Various
> things the persistent branch are unfortunate, but I don't think we have
> much room to improve them.
>
>> One nice thing would be to be able to specify the flags for all paths
>> matching some pattern. This may seem complicated, but doesn’t add much
>> more conceptual overhead in addition to the `*` special path.
>
> This sounds a good idea, (but I don't plan to write it myself in the
> short terms)

Basically, I just wanted to know if you see anything in the current
design that would make my proposed generalization difficult.

>> For the name of the config, see the discussion below (we should use
>> the same names for the config and CLI flags).
>
> +1 for using the same name
>
>>
>>> 4) adding more flag
>>>
>>> They are a couple of check that does not have there own flag yet and
>>> are only covered by `--force`. For example to push new heads. I know
>>> that Manuel Jacob had idea about how to express these flag, so I CCed
>>> him on this email.
>>
>> The basic idea is simply to have a flag for each check to turn it off
>> or on.
>>
>> One issue is the naming, which probably requires some bideshedding.
>> The existing "--new-branch" never really made sense to me (it sounds
>> as if it always added a new branch instead of disabling some check).
>>
>> Before shipping a bunch of new flags, it would be good to get it
>> right. Another reason for having a better naming scheme would be that
>> a common prefix (not every flag will start with "new") creates a bit
>> of grouping and aids auto-completion.
>>
>> For disabling checks, prefixing it with "--allow-" makes sense to me.
>> The first flags to add would be:
>> --allow-new-branch: allow adding new branch on destination
>> --allow-new-head: allow increasing the number of heads on a branch on
>> destination
>
> So --allow-new-branch and --no-allow-new-branch ? (or maybe
> --deny-new-branch) ?

I probably would have picked --disallow-new-branch, but maybe something
else (like "deny-…") is more correct? I’m not a native speaker…

>> For the checks about not pushing obsolete, orphan, divergent and
>> similar changesets, I proposed some changes (I think the existing
>> checks miss problematic cases and reject legitimate ones).
>
> Do you have details on these case ?

In the following, let’s limit the discussion on orphans for now.

The optimal check would probably be whether the push (containing
changesets and/or obsmarkers) results in more orphans on the server.

The current check doesn’t in general prevent pushing obsmarkers that
make changesets orphan on the server. One part of the problem is that
the current check has an early exit if no changeset is going to be
transferred on the push, ignoring whether obsmarkers are going to be
transferred. But even without the early exit, the current approach won’t
work. If we have A on the client and A←B on the server, and prune A on
the client, the current check won’t realize that B is going to be orphan
on the server.

The current check focuses on the revisions specified by --rev (or all
heads on the client by default), no matter whether they are going to be
transferred or not. This means that pushing fails even if the changesets
are already orphan on the server. This prevents pushing unrelated branches.

I’ve added a test case to
https://bz.mercurial-scm.org/show_bug.cgi?id=6372#c11 that shows
examples for both a false positive and a false negative.

>> Pierre-Yves was concerned about breaking expectations of users relying
>> on the old behavior, so this was never released.
>
> Was I ? Evolution is still experimental, so reasonable behavior change
> should be fine, but there might have been other issues.

See changeset 6063c1857d0a2d4dd985807c31ebf68aeb0bbf38. I think most of
the concerns were valid. Let’s take some time to mature these checks.

>> By making it possible to turn off and on various variants of the
>> checks, new behaviors can be designed and developed in an incremental
>> way. This is especially useful considering that more advanced
>> detection algorithms depend on accurate obsmarker discovery, which is
>> currently not in core.
>>
>>> This work is not my primary focus, but hope to make enough progress
>>> to have most of it completed by the 5.8 freeze, in one month.
>>
>> I won’t be able to start the “split --force” effort before the 5.8
>> freeze, as I‘m in the process of renovating my flat, but I’ll try to
>> give feedback about your efforts. Thanks for CCing me! In the next
>> release cycle, I will be able to spend time implementing stuff.
>
> 5.8 freeze is this week. So I'll focus on the "multi-path` aspect of
> this work (see earlier in my original message) and we can look into the
> new behavior flag for 5.9.

Sounds good!

> Cheers,
>

_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

Re: development heads up: push/pull improvements

Pierre-Yves David-2


On 4/16/21 3:41 PM, Manuel Jacob wrote:

> On 13/04/2021 12.16, Pierre-Yves David wrote:
>> On 4/13/21 3:03 AM, Manuel Jacob wrote:
>>> On 17/03/2021 16.05, Pierre-Yves David wrote:
>>>> Hello everyone,
>>>>
>>>> I have been working on improvements to push and pull. The core goal
>>>> can be summarized as:
>>>> * make it simpler to push/pull to multiple destinations
>>>> * make it simpler to control default behavior from various
>>>> destinations.
>>>>
>>>> The first bits of this already landed.
>>>>
>>>> * Support for multiple destinations for pull (push is in review))
>>>>    https://www.mercurial-scm.org/repo/hg-committed/rev/685383486d0a
>>>> * Support for default value for path suboption:
>>>>    https://www.mercurial-scm.org/repo/hg-committed/rev/e3f15c553522
>>>>
>>>> My plan is to follow up with an handful of other improvements:
>>>>
>>>> 1) Make it possible for a path (in [paths] section), to reference
>>>> another one using `path://PATHNAME`, inheriting its configuration.
>>>> The inherited configuration can then be overwritten in the new path
>>
>> Regarding this, I have done most of the necessary work for this last
>> week, and I am in the process making the patches ready and sent.
>
> Thank you for doing the work!
>
>> The main issue is the impact on `hg path` and related templates,
>> because the data structure change.
>>
>> I is also not possible to simply turn the [paths] entry into a "list"
>> field since this will break too much BC for people using " " in their
>> path.
>>
>> I am thinking about a `my-path:urls` attribute ?
>
> Would the only difference to specifying the URLs in the current way that
> spaces have to be escaped?

And any other list separator from our config list format (for the
specification of our config list format, see `hg help fhtagn`)

I did not went the `my-path:urls` root, because suboption needs a main
option, and with `my-path:urls` we have nothing left to put in our main
option.

Instead I introduce a `my-path:multi-urls` boolean that control the
parsing behavior. https://phab.mercurial-scm.org/D10452

>
>>>> 2) Make is possible for a path to reference a list of other paths. eg:
>>>>
>>>>    [paths]
>>>>    main = https://mercurial-scm.org/repo/hg
>>>>    committed = https://mercurial-scm.org/repo/hg-committed
>>>>    all = path://main, path://committed
>>>>
>>>> 3) add sub-options to control usage of existing flags. For example
>>>> the following config would make `--new-branch` on by default for the
>>>> `devel` path.
>>>>
>>>>    [paths]
>>>>    devel = ssh://foo…
>>>>    devel:new-branch=yes
>>>>
>>>> The possible values would be:
>>>>
>>>> * never: the flag is never set, using --new-branch would abort the push
>>>> * no: the flag default to False, passing --new-branch enables it
>>>> * default: the default value for the flag is used
>>>> * yes: the flag default to True, passing --no-new-branch disables it
>>>> * always: the flag is always set, --no-new-branch would abort the push
>>>
>>> I really like this feature. I don’t really see the point in "always",
>>> but we can have it for symmetry with "never".
>>>
>>> Speaking of defaults, it would make sense to me to allow pushing new
>>> branches in draft phase by default, since the original point of
>>> disallowing it was probably to prevent people from making the branch
>>> name permanent, which isn’t a problem with draft changesets.
>>
>> This is still going to be an issue, because once pushed, they can
>> easily get "silently" published, and we don't have a check for that.
>
> I see the point. There’s stuff we could do to prevent the accidental
> pushes, but it still might not be enough to allow new branches in draft
> phase by default. I’m fine with leaving the current behavior.

We might eventually gain enough check to make this kind of things True.
However I am also quite convinced that the future of draft()/public
boundary for the mass lie withing the branch/subbranch idea (currently
topic are such sub-branch) and that should reduce friction and risk
around permanent-branch quite a lot.


>> Various things the persistent branch are unfortunate, but I don't
>> think we have much room to improve them.
>>
>>> One nice thing would be to be able to specify the flags for all paths
>>> matching some pattern. This may seem complicated, but doesn’t add
>>> much more conceptual overhead in addition to the `*` special path.
>>
>> This sounds a good idea, (but I don't plan to write it myself in the
>> short terms)
>
> Basically, I just wanted to know if you see anything in the current
> design that would make my proposed generalization difficult.

Nothing obvious, but the devils is in the details, as people might be
using path name that could be interpreted as pattern ?

>>> For the name of the config, see the discussion below (we should use
>>> the same names for the config and CLI flags).
>>
>> +1 for using the same name
>>
>>>
>>>> 4) adding more flag
>>>>
>>>> They are a couple of check that does not have there own flag yet and
>>>> are only covered by `--force`. For example to push new heads. I know
>>>> that Manuel Jacob had idea about how to express these flag, so I
>>>> CCed him on this email.
>>>
>>> The basic idea is simply to have a flag for each check to turn it off
>>> or on.
>>>
>>> One issue is the naming, which probably requires some bideshedding.
>>> The existing "--new-branch" never really made sense to me (it sounds
>>> as if it always added a new branch instead of disabling some check).
>>>
>>> Before shipping a bunch of new flags, it would be good to get it
>>> right. Another reason for having a better naming scheme would be that
>>> a common prefix (not every flag will start with "new") creates a bit
>>> of grouping and aids auto-completion.
>>>
>>> For disabling checks, prefixing it with "--allow-" makes sense to me.
>>> The first flags to add would be:
>>> --allow-new-branch: allow adding new branch on destination
>>> --allow-new-head: allow increasing the number of heads on a branch on
>>> destination
>>
>> So --allow-new-branch and --no-allow-new-branch ? (or maybe
>> --deny-new-branch) ?
>
> I probably would have picked --disallow-new-branch, but maybe something
> else (like "deny-…") is more correct? I’m not a native speaker…

am a not a native speaker either. disallow seems fine, but at that rate
`--no-allow` will be more standard and we should probably go with that.

>>> For the checks about not pushing obsolete, orphan, divergent and
>>> similar changesets, I proposed some changes (I think the existing
>>> checks miss problematic cases and reject legitimate ones).
>>
>> Do you have details on these case ?
>
> In the following, let’s limit the discussion on orphans for now.
>
> The optimal check would probably be whether the push (containing
> changesets and/or obsmarkers) results in more orphans on the server.
>
> The current check doesn’t in general prevent pushing obsmarkers that
> make changesets orphan on the server. One part of the problem is that
> the current check has an early exit if no changeset is going to be
> transferred on the push, ignoring whether obsmarkers are going to be
> transferred. But even without the early exit, the current approach won’t
> work. If we have A on the client and A←B on the server, and prune A on
> the client, the current check won’t realize that B is going to be orphan
> on the server.
>
> The current check focuses on the revisions specified by --rev (or all
> heads on the client by default), no matter whether they are going to be
> transferred or not. This means that pushing fails even if the changesets
> are already orphan on the server. This prevents pushing unrelated branches.
>
> I’ve added a test case to
> https://bz.mercurial-scm.org/show_bug.cgi?id=6372#c11 that shows
> examples for both a false positive and a false negative.

I see.

>>> Pierre-Yves was concerned about breaking expectations of users
>>> relying on the old behavior, so this was never released.
>>
>> Was I ? Evolution is still experimental, so reasonable behavior change
>> should be fine, but there might have been other issues.
>
> See changeset 6063c1857d0a2d4dd985807c31ebf68aeb0bbf38. I think most of
> the concerns were valid. Let’s take some time to mature these checks.
>
>>> By making it possible to turn off and on various variants of the
>>> checks, new behaviors can be designed and developed in an incremental
>>> way. This is especially useful considering that more advanced
>>> detection algorithms depend on accurate obsmarker discovery, which is
>>> currently not in core.
>>>
>>>> This work is not my primary focus, but hope to make enough progress
>>>> to have most of it completed by the 5.8 freeze, in one month.
>>>
>>> I won’t be able to start the “split --force” effort before the 5.8
>>> freeze, as I‘m in the process of renovating my flat, but I’ll try to
>>> give feedback about your efforts. Thanks for CCing me! In the next
>>> release cycle, I will be able to spend time implementing stuff.
>>
>> 5.8 freeze is this week. So I'll focus on the "multi-path` aspect of
>> this work (see earlier in my original message) and we can look into
>> the new behavior flag for 5.9.
>
> Sounds good!
>
>> Cheers,
>>
>

--
Pierre-Yves David
_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel