Re: Patch for repo groups API documentation

[Mads Kiilerich]

(Please always send to the public mailing list - not just private.)

Thanks. I applied the patch to the stable branch, with some trivial 
changes for consistency.


(Note that get_repo_group already had a docstring in api.py that is a 
bit more verbose and possibly better. I'm keeping an eye on making these 
converge and making it clear which one is better.)


/Mads


On 27/12/2022 19:38, Louis Bertrand wrote:

Hello Mads,
I'm catching up on a promised update to the API docs for repo groups. Please 
see attached patch for docs\api\api.rst
Hope this helps
  --Louis

--
Louis Bertrand, P.Eng.
Professor, Faculty of Science, Engineering and Information Technology
Durham College

-Original Message-
From: Mads Kiilerich 
Sent: October 29, 2022 12:08 PM
To: Louis Bertrand 
Subject: Re: Patch for repo groups API documentation

[EXTERNAL EMAIL - USE CAUTION]

(Private reply)

Thanks. But the patch seems to be for your changes combined with a merge. That 
is hard to apply here.

Can you push the changes instead, using something like hg push -f -r 
8b9e6a60ece02ca505d32e48f5fb19829ffc5490
https://kiile...@kallithea-scm.org/repos/kallithea-incoming
<>

That should hopefully make it possible for me to untangle and extract your 
changes cleanly.

(But you are also welcome to clean it up and send in other ways if you
prefer.)

/Mads


On 29/10/2022 15:42, Louis Bertrand wrote:

Hi,
I started documenting the repository group API. Here's a patch, but it might be 
messy because of conflicts due to whitespace adjustments while I was working on 
it.
Let me know if it's a problem and I'll base the changeset on a more recent 
version.
All the best
   --Louis

--
Louis Bertrand, P.Eng.
Professor, Faculty of Science, Engineering and Information Technology
Durham College




This message is intended only for the named recipients. This message may 
contain information that is confidential or exempt from disclosure under 
applicable law. Any dissemination or copying of this message by anyone other 
than a named recipient is strictly prohibited. If you are not a named recipient 
or an employee or agent responsible for delivering this message to a named 
recipient, please notify us immediately, and permanently destroy this message 
and any copies you may have. Warning: Email may not be secure unless properly 
encrypted.

___
kallithea-general mailing list
kallithea-general@sfconservancy.org
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general




___
kallithea-general mailing list
kallithea-general@sfconservancy.org
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general

Re: About API code comments and some behavior.

[Mads Kiilerich]

On 18/12/2022 10:48, toras wrote:

>> Attachment: fix-update_repo_group-2.patch
>
> Lots of things happening in that patch. Can you explain in more 
details what is changed and why ... and perhaps do it in several
> simpler changesets? 

...

The second is to modify the log output.
Sorry for the confusion, the change to the f string was just for my 
own viewing pleasure, not related to the issue.



Ok. But I will just start out by making this piece of code use lazy %s 
expansion for logging like we do in all other places.



The entities enumerated by recursive_groups_and_repos() to update the 
full path of the child elements are processed with log output, but the 
starting repository group has already had its entities updated before 
the loop.
So, for example, updating the name from 'GroupA' to 'GroupB' will 
result in the following log output

(Only the origin entity. Child elements are correct logs.)

  [kallithea.model.repo_group] Fixing group GroupB to new name GroupB

The following logs should be correct.

  [kallithea.model.repo_group] Fixing group GroupA to new name GroupB

For the purpose of logging the name before the change, the patch 
outputs the log before updating the entity and skips the originating 
entity in a loop process.



Right - thanks for clarifying. I applied fix doing just that, but also 
made sure we don't do excessive logging when parameters specified 
without changing.



Thanks for the contribution.

/Mads

___
kallithea-general mailing list
kallithea-general@sfconservancy.org
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general