[PATCH 2 of 2] subrepo: hg pushes into local subrepos, after with source
Александр Литягин
alexraynepe196 at gmail.com
Wed Sep 18 08:34:58 UTC 2024
17.09.2024 22:32, Matt Harbison пишет:
>
>> On Sep 16, 2024, at 6:59 PM, Александр Литягин
>> <alexraynepe196 at gmail.com> wrote:
>>
>>
>> 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.
>>
> I’m confused by all of this. Can you paste the .hgsub file here? I
> don’t think you meant “I guess using URL” the way I read it.
>
there sample from .hgsub of my job project (i hide real names with
capital-akronims):
ware/BRAND/NAME-c
=[hg]\\SERVER\Development\vector\spodes\NAME.BRAND\c.hggit\
ware/atCmdDevice =
[hg]https://alexraynepe196@hg.osdn.net//hgroot/atcmddevice/atcmddevice
here \\SERVER\Development hosted in local net of my client. i haveno
access is from my workplace.
and https://alexraynepe196@hg.osdn.net - is my repo. But https: access
can only read, I push to in via ssh: access. https: enough for client,
so this is in hgsub.
> What manual work is involved here? What does it mean to push and keep
> changes private? That by definition isn’t private. You need to be
> really careful here because subrepos are lazy and push *everything*,
> not just the revisions that were locked into the parent repo. Secret
> phase is the only way to prevent something from being pushed.
>
i need take ny work on flash, and test it on my client area, before
publish subrepos to their sources.
Current behaviour make me to push every subrepo by their own - i made
copyes of them on flash drive, and push them separately before push
root-repo.
This works since push command can denote target path, so i can push
subrepo to any target, besides whar source declared in .hgsub
> It sounds like you don’t have write access to the remote subrepo- do
> you have write access to the remote parent repo?
This situation not strange, i guess - i have no access to push into
subrepos, but my leader have. i need test my subrepo chages, and pass
them to leader. in both stages i need someway pass changes (to
test-place or to leader) around of source.
> Can you convince the person who does to adjust the .hgsub file to use
> the standard sub=sub style?
This is not an option in my case : to my clients i have to pass project
in a way that they can load and built it - so i used https: public
access URLs in .hgsub, and won't give them ssh: access, with a lot of
work about access keys.
>>>> 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?
>>
> For one, declaring a subrepo with an absolute path only pushes it to
> that absolute location. The only reason I can think of for having an
> absolute path to the subrepo is because you want to break out of the
> distributed model, maybe because of the size of the files in it.
>
> For another, subrepos try very hard not to leave the remote copy in an
> inconsistent state. It will recurse into the deepest repo, and then
> push as it unwinds the stack. That way, no parent repo has a dangling
> reference into a subrepo revision that doesn’t exist. If an error
> occurs, it stops. A switch to ignore errors is a non-starter.
>
> Subrepos can also have subrepos themselves, so this gets really
> complex, really quickly.
>
> Yes, it’s a distributed SCM, but some features like subrepos and
> largefiles/LFS inherently have centralized SCM behaviors.
But we have already subpathes feature - that distributes it `centralized
SCM behaviors`, and looks like this `centralization` not ruined. this
patch make work similar with subpathes, itn't it?.
>>> 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 problem is the push failed. How would you determine that
> continuing to push won’t put the remote parent in an inconsistent state?
Well, i not think about it though to final, and stay on conditions
enough for me now. In this patch push --force success at least when
changes passed to target subrepo (on my flashdrive). As a result, with
this condition i have full copy on target, and possibly some additional
changes on sources of sub-repos, that laer can be referenced by root-repo
>>> 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.
>
> I don’t understand this at all. If it is an absolute subrepo, there’s
> the same https:// url in the .hgsub file in every clone. All that you
> need to do is replace that url with the local name. That’s the same
> in every clone, because you name it relative to the parent repo.
hm, thanks, i not smart enough to got it before
>> So with `subpaths ` solution i need prepare for every flash-drive a
>> personal copy of repo with hgrc turned for that pathes. Even with a
>> few flashes it rapidly goes into nightmare.
>>
> What you might be able to do is add a file with the proper subpaths
> config, and the use the %include directive in the parent repo’s hgrc
> file. Yes, you have to edit the file in each clone once, but after
> that it’s managed by the tracked file if anything changes. (Note that
> you should trust everyone who can commit to the repo if you do this.
> You don’t want someone to add a [hooks] config to the file, and have
> things run when you pull and update.)
>>
>> 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.
>>
> It would be expected from push, only if the subrepo reference was
> relative. That’s the reason for two different reference types- two
> different behaviors.
>
> My suggestion, from most to least preferred is:
>
> 1) Have the remote parent’s owner adjust .hgsub to use relative paths.
> Subrepos are a feature of last resort because of the ways it breaks
> normal distributed model, and absolute references are in a much less
> used area of a lesser used feature.
>
> 2) Depending on how/if you submit things upstream, if the owner won’t
> fix it, you might want to start your own branch with a fixed .hgsub
> file. Yes, you’ll have to pull and merge as upstream changes are
> added, but then you don’t have to deal with these issues.
>
> 3) If none of that works, make the subpaths work. This is definitely
> the most fragile.
Looks like 1) can work for me.
But at final : on my sensation - mercurial is light/easy alternative to
git, that for it chooses. I not understand why mercurial users must
suffer with hgrc configure, instead just point on command what they want.
So, maybe we can introduce an option for push, says like
--relative-subs, that make an subpath work behind - substitute all
sources with releative pathes.
Is such option can be apropriated for mercurial project ?
>> Imho `subpaths ` solution could be suitable, if subpathes declared in
>> named sets - with name of push target. Or it alredy can?
>>
> It’s not a feature as far as I know- I’ve never used the subpaths
> config myself because I always use sub=sub. I only knew about it
> because of the tests. Even though it says that it needs to be defined
> in the parent config file, I’m not sure that it would filter out the
> config if it was in your user level hgrc, for example.
>
>>>> 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/20240918/78ce3310/attachment.html>
More information about the Mercurial-devel
mailing list