ShareSafePlan

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

ShareSafePlan

Martin von Zweigbergk via Mercurial-devel
I read https://www.mercurial-scm.org/wiki/ShareSafePlan. It has examples of things that *should* be read from the source repo, but I don't see examples of things that should *not* be read from the source repo.

Can you give examples of things that would break if a share repo read its configs as usual (system -> user -> repo), but also looked at the source repo's configs (system -> user -> source repo -> share repo)?

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

Re: ShareSafePlan

Pierre-Yves David-2


On 9/15/20 7:35 PM, Martin von Zweigbergk via Mercurial-devel wrote:
> I read https://www.mercurial-scm.org/wiki/ShareSafePlan. It has
> examples of things that *should* be read from the source repo, but I
> don't see examples of things that should *not* be read from the source repo.
>
> Can you give examples of things that would break if a share repo read
> its configs as usual (system -> user -> repo), but also looked at the
> source repo's configs (system -> user -> source repo -> share repo)?

I a still a bit confused at your question because about any config are
relevant for this category as long as the user want to set it up
specifically for the repository without impact on the potential shares.
User might want different configuration from one share to another, right
? In the same way it might want different configuration between the
source repository and the share. That could be anything, username,
hooks, extensions, paths, alias, anything, really.

So any config that does not directly impact the repository format (that
will be shared with the share anyway) could be relevant for that file.

I don't know if this answer your question, if not, I will need a
rephrasing of your question.

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: ShareSafePlan

Martin von Zweigbergk via Mercurial-devel


On Tue, Sep 15, 2020 at 12:34 PM Pierre-Yves David <[hidden email]> wrote:


On 9/15/20 7:35 PM, Martin von Zweigbergk via Mercurial-devel wrote:
> I read https://www.mercurial-scm.org/wiki/ShareSafePlan. It has
> examples of things that *should* be read from the source repo, but I
> don't see examples of things that should *not* be read from the source repo.
>
> Can you give examples of things that would break if a share repo read
> its configs as usual (system -> user -> repo), but also looked at the
> source repo's configs (system -> user -> source repo -> share repo)?

I a still a bit confused at your question because about any config are
relevant for this category as long as the user want to set it up
specifically for the repository without impact on the potential shares.
User might want different configuration from one share to another, right
? In the same way it might want different configuration between the
source repository and the share. That could be anything, username,
hooks, extensions, paths, alias, anything, really.

So any config that does not directly impact the repository format (that
will be shared with the share anyway) could be relevant for that file.

The wiki page talks mostly (only?) about what can break if we don't use the source repo's data. I was wondering what might break if we always read the source repo's config. Do you have examples?

You seem to bring up the question of what's most *convenient* for the user. That's also a great question. It's not at all obvious to me what the answer is. Could you (or Pulkit?) also document the plans for that on the wiki?


I don't know if this answer your question, if not, I will need a
rephrasing of your question.

Cheers,

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

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

Re: ShareSafePlan

Pulkit Goyal
On Wed, Sep 16, 2020 at 4:20 AM Martin von Zweigbergk
<[hidden email]> wrote:

>
>
>
> On Tue, Sep 15, 2020 at 12:34 PM Pierre-Yves David <[hidden email]> wrote:
>>
>>
>>
>> On 9/15/20 7:35 PM, Martin von Zweigbergk via Mercurial-devel wrote:
>> > I read https://www.mercurial-scm.org/wiki/ShareSafePlan. It has
>> > examples of things that *should* be read from the source repo, but I
>> > don't see examples of things that should *not* be read from the source repo.
>> >
>> > Can you give examples of things that would break if a share repo read
>> > its configs as usual (system -> user -> repo), but also looked at the
>> > source repo's configs (system -> user -> source repo -> share repo)?
>>
>> I a still a bit confused at your question because about any config are
>> relevant for this category as long as the user want to set it up
>> specifically for the repository without impact on the potential shares.
>> User might want different configuration from one share to another, right
>> ? In the same way it might want different configuration between the
>> source repository and the share. That could be anything, username,
>> hooks, extensions, paths, alias, anything, really.
>>
>> So any config that does not directly impact the repository format (that
>> will be shared with the share anyway) could be relevant for that file.
>
>
> The wiki page talks mostly (only?) about what can break if we don't use the source repo's data. I was wondering what might break if we always read the source repo's config. Do you have examples?
>
> You seem to bring up the question of what's most *convenient* for the user. That's also a great question. It's not at all obvious to me what the answer is. Could you (or Pulkit?) also document the plans for that on the wiki?

I have updated the wiki page to mention that we don't want to share
all requirements and configs. Let me know if I miss something and I
will be happy to fix that.

Now talking about examples, for requirements, we have `exp-sparse`
requirements. In the future, if we change the store or have wdir
specific something which needs a requirement, we will need it.
Requirements cannot be negated in the shares hence having a non-shared
requirements file is good.
About config, there are configs that are related to the non-shared
requirements like all configs related to sparse extension (if there is
any apart from enabling extension). We don't want to share them as
sparse or similar extensions can wrap stuff without checking for
requirements and lead to unwanted results. As Pierre-Yves also
mentioned, if we look more loosely, it can be anything.

Last night on IRC you mentioned that we can do `extensions.sparse=!`
in the shares. Having shares explicitly set/unset configs that are
shared is also a solution. However, in this case, shares control which
config option they want to disable. The shared source has no way to
specify it's private config whereas shares can. This may also lead to
warnings and signboards like "if you share this repo, kindly set these
configs in the shared destination." which is not a good design IMO.

>
>>
>> I don't know if this answer your question, if not, I will need a
>> rephrasing of your question.
>>
>> Cheers,
>>
>> --
>> Pierre-Yves David
>> _______________________________________________
>> Mercurial-devel mailing list
>> [hidden email]
>> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

Re: ShareSafePlan

Martin von Zweigbergk via Mercurial-devel


On Wed, Sep 16, 2020 at 1:26 AM Pulkit Goyal <[hidden email]> wrote:
On Wed, Sep 16, 2020 at 4:20 AM Martin von Zweigbergk
<[hidden email]> wrote:
>
>
>
> On Tue, Sep 15, 2020 at 12:34 PM Pierre-Yves David <[hidden email]> wrote:
>>
>>
>>
>> On 9/15/20 7:35 PM, Martin von Zweigbergk via Mercurial-devel wrote:
>> > I read https://www.mercurial-scm.org/wiki/ShareSafePlan. It has
>> > examples of things that *should* be read from the source repo, but I
>> > don't see examples of things that should *not* be read from the source repo.
>> >
>> > Can you give examples of things that would break if a share repo read
>> > its configs as usual (system -> user -> repo), but also looked at the
>> > source repo's configs (system -> user -> source repo -> share repo)?
>>
>> I a still a bit confused at your question because about any config are
>> relevant for this category as long as the user want to set it up
>> specifically for the repository without impact on the potential shares.
>> User might want different configuration from one share to another, right
>> ? In the same way it might want different configuration between the
>> source repository and the share. That could be anything, username,
>> hooks, extensions, paths, alias, anything, really.
>>
>> So any config that does not directly impact the repository format (that
>> will be shared with the share anyway) could be relevant for that file.
>
>
> The wiki page talks mostly (only?) about what can break if we don't use the source repo's data. I was wondering what might break if we always read the source repo's config. Do you have examples?
>
> You seem to bring up the question of what's most *convenient* for the user. That's also a great question. It's not at all obvious to me what the answer is. Could you (or Pulkit?) also document the plans for that on the wiki?

I have updated the wiki page to mention that we don't want to share
all requirements and configs. Let me know if I miss something and I
will be happy to fix that.

Thanks. I was hoping for something about what's most useful for the user. It seems to me that there are two ways of doing it:

1. Read the source repo's .hg/hgrc file by default and add a .hg/nonsharedhgrc
2. Don't read the source repo's .hg/hgrc file by default and add a .hg/sharedhgrc
3. Mercurial decides on a per-config basis if it should consult the source repo's config.

You have chosen solution 1 (to share by default). For comparison, we currently don't read the source repo's .hg/hgrc file and we don't have a way of sharing config. I was hoping for a discussion about the pros and cons you considered before you chose to share by default. Things I can think of:

1. Sharing by default: Hooks etc need to be shared for correctness. It's useful if e.g. templates, paths, and many other configs are shared by default.
2. Sharing by default: More similar to current behavior.
3. Mercurial decide per config: Possibly easiest for the user in the simple cases. Weird because Mercurial doesn't currently do anything like this. Still need (?) a mechanism for cases when the user wants to override Mercurial's decision.

It might also be nice to list a few configs that you would want to share and a few things you would not want to share. It might be obvious to you, but it might not be obvious to readers.

By the way, you mention that "storage/format configuration" needs to be shared. Can you give an example? Shouldn't they all have their corresponding requirements in .hg/requires, so the config doesn't matter once the repo has been created?


Now talking about examples, for requirements, we have `exp-sparse`
requirements. In the future, if we change the store or have wdir
specific something which needs a requirement, we will need it.
Requirements cannot be negated in the shares hence having a non-shared
requirements file is good.
About config, there are configs that are related to the non-shared
requirements like all configs related to sparse extension (if there is
any apart from enabling extension). We don't want to share them as
sparse or similar extensions can wrap stuff without checking for
requirements and lead to unwanted results. As Pierre-Yves also
mentioned, if we look more loosely, it can be anything.

Last night on IRC you mentioned that we can do `extensions.sparse=!`
in the shares. Having shares explicitly set/unset configs that are
shared is also a solution. However, in this case, shares control which
config option they want to disable. The shared source has no way to
specify it's private config whereas shares can. This may also lead to
warnings and signboards like "if you share this repo, kindly set these
configs in the shared destination." which is not a good design IMO.

>
>>
>> I don't know if this answer your question, if not, I will need a
>> rephrasing of your question.
>>
>> Cheers,
>>
>> --
>> Pierre-Yves David
>> _______________________________________________
>> Mercurial-devel mailing list
>> [hidden email]
>> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

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