[PATCH 2 of 2] subrepo: hg pushes into local subrepos, after with source

[Александр Литягин]

16.09.2024 19:24, Matt Harbison пишет:
>
>> On Sep 13, 2024, at 2:34 PM, Александр Литягин<alexraynepe196 at gmail.com> wrote:
>>
>> Hallow Matt!
>>
>> i try to make some test, but i guess it take more then month
>>
>> try explain what i fix here:
>> 1) have repo:
>>      root/         - repo with hg-subs:
>>          /sub      - hg-subrepo, from some remote
>>          .hgsub  - contains /sub=[hg]<some url>
> So if I understand this correctly, your top level repo has a .hgsub file with an absolute path (in this case a url starting with http) on the right side?  That’s why it’s not pushing relative to where the parent repo is pushing- you specified an absolute location.  The recommendation is for the left and right side of the file to be the same (in your case “sub=sub”).  Otherwise you run into surprises like this.

This is not just a surprises - i  guessed using URL - that is subrepo 
intended for. When you pulled subrepo from remote repo, wich you not 
allowed for push - inevitable got this situation.

And here is still some ways to pass changes with a lot of boring manual 
work with subrepos, that can made with mistakes.

Another situation - if you wan`t push changes to remote, but keep it for 
some private work. There we get rid to using `subpaths`, you described 
below.

>> 2) have copy of above repo  on local file system - usualy i use flash-drive. so call this copy <flash-copy>
>> 3) try push repo into flash-copy.
>>
>> current implementation push sub to it`s source <some url>. and worse - if this url not accesible, push fails.
>>
>> This patch supposes that pushing into flash-copy expects passing changes from root/sub -> flash-copy/sub. And it does such push into flash-copy/sub after pushing into -> <some url>
>> If we run with --force - this patch ingnores failure on push to <some url>, so push -> flash-copy/sub makes anyway.
>> Forced push supposed success if any of <some url> or flash-copy/sub succesed.
> Unfortunately, this is too complicated and breaks existing workflows.

what workflow it breaks? as i thought - hg is distributed SCM, that is 
desinged for a such distribution way - via any copies. If we got a 
complete copy of changes - there should be no problem?

>   Also, I don’t think there’s an existing concept of —force => “ignore errors”.
surprised, i guessed this option exactly for errors override.  Well, 
some another option introduce for it?

> The closest thing I can think of is overriding the check that push will add a new head, and I think everyone agrees that is bad (it should have been a flag specific to that error, not disabling all checks).
>
> The good news is that this is a known potential problem, with an existing solution.  If you can’t just edit the .hgsub file to the recommended form, you can put a “subpaths” section in the root repo’s hgrc file.  See the end of “hg help subrepos”, and “hg help config.subpaths” for details.
It looks not solves my problem - i need a complete local repo copy of 
flash, intended for pass it on another workstation. And on different 
flash-drives it can be on different pathes.

So with `subpaths ` solution i need prepare for every flash-drive an 
personal copy of repo with hgrc turned for that pathes. Even with a few 
flashes it rapidly goes into nightmare.

That is why this patch designed  - for easy push to into arbitrary 
local-pathes. No need remember about sources, subpathes - just point 
destination, and get a changes on it. That behaviour, i  guess, people 
expected from push.


Imho `subpaths ` solution could be suitable, if subpathes declared in 
named sets - with name of push target. Or it alredy can?


>
>> That what this patch do.
>>
>>
>> On 13.09.2024 1:55, Matt Harbison wrote:
>>>>> On Sep 12, 2024, at 5:46 PM,alexraynepe196 at gmail.com wrote:
>>>> # HG changeset patch
>>>> # User alexrayne
>>>> # Date 1726176902 -10800
>>>> #      Fri Sep 13 00:35:02 2024 +0300
>>>> # Node ID fca662b31c85f27ecc0221c64666cafd9a9bbb97
>>>> # Parent  a000ac71e41a56e3b1c7697f44e34683d0fd47bd
>>>> subrepo: hg pushes into local subrepos, after with source.
>>>>         when --force claimed, subrepo push into local besides source
>>> Can you write some *.t test to show the problem before making changes?  Then the test will change with the commit, and prevent future regressions.  I’m not sure what you’re trying to fix here.
>>>
>>> Additionally, you should run the test-check-*.t and test-*subrepo*.t tests locally.  I can tell this commit message would be flagged for not following the usual format.  Also, an existing subrepo test might change with your change, and then you might not need to write your own test.
>>>
>>> Thanks!
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20240917/35cd6369/attachment.html>