Arch::...Bunches(3pm)

✨ Arch::RevisionBunches — bestie edition ✨

okay so this is Arch::RevisionBunches, a Perl module from the User Contributed Perl Documentation collection, and it's literally here to manage bunches of related revisions 💖

---

🌸 NAME 🌸

Arch::RevisionBunches — manage bunches of related revisions 🎀

---

🦋 SYNOPSIS 🦋

no thoughts, just vibes, and also this exact code:

use Arch::RevisionBunches;
use Arch::Tree;

my $rb = Arch::RevisionBunches->new;
my $tree = Arch::Tree->new(".", own_logs => 1);
$rb->add_revision_descs($tree->get_history_revision_descs);
$rb->rebunch(25);  # the default is 50
foreach my $bunch ($rb->get) {
    print "$bunch->{version}\n";
    print "    $_->{name}\t$_->{summary}\n"
        foreach @{$bunch->{revision_descs}};
}
foreach my $bunch ($rb->reverse_revision_descs->rebunch(30)) {
    print $bunch->{name1};
    print " .. $bunch->{name2}" if $bunch->{name2};
    print " ($bunch->{daysago1}";
    print " .. $bunch->{daysago2}" if $bunch->{name2};
    print " days ago)\n";
}

periodt. 💅

---

💜 DESCRIPTION 💜

so basically this class is the wingman for front-ends that need to group revisions together 🫶. and why does that matter?? because when the version you're showing has, like, thousands of revisions, dumping them all at once is giving chaos 😭. the front-end can decide to show expandable bunches of 100 revisions each. iconic behaviour honestly.

there's support for revision descriptions — that's summary, date, creator, email, and in some cases the associated file name and/or the associated version. slay.

there's a constraint, and it's a by-convention thing: one bunch may only contain revisions of the same version, and the ones associated with the same file if applicable. it's possible to define an order of versions. it's also possible to recreate bunches (that's rebunch) using a different number of revisions. BUT — and this is important, bestie — that constraint defines the actual number of revisions in different bunches, so it is not guaranteed to be the same. the vibes are flexible, the count is flexible, that's just how it is 💀

---

🎀 METHODS 🎀

the following methods are available:

new, init, add_revision_descs, versions, rebunch, get, clear, reverse_revision_descs, versions, filepaths.

(yes, versions really is listed twice in there. no cap, that's just the list.)

⭐ new [%args]

construct an Arch::RevisionBunches object ✨

the %args get passed straight to the init method, no middleman.

⭐ init [%args]

the %args keys may be:

• bunch_size — use this as the default bunch size instead of 50 🌸
• max_sumlen — maximal summary length to keep, including trailing ellipsis; must be greater than 5 ⚠️
• version — if set, then all revisions are assumed to be of one version; otherwise multiple versions are assumed 🦋
• final_revision — the final revision for which the revision bunches are constructed
• final_filepath — the final filepath for which the revision bunches are constructed

ngl, those last two %args keys, final_revision and final_filepath? they are not really used yet. the author said it, not me 🙈

⭐ add_revision_descs [%constant_fields]

add revision descriptions, which is an arrayref of hashes 💖. go look at the other classes that return such revision descriptions if you need the tea.

if the %constant_fields is given, then add these to all revision descriptions (rarely needed, bestie).

return the object — which means you can chain a get or rebunch method call right onto it. chain energy 🔥

⭐ rebunch [bunch_size]

group newly added revisions if no bunch_size is specified. otherwise, regroup all revisions using a given bunch_size. the default bunch size may be specified in the constructor ✨

return the same thing get does.

⭐ get

return bunches — that's an arrayref in scalar context, an array in list context 🌈

each bunch is a hashref with these keys:

revision_descs
name1 daysago1 time1 tz1
name2 daysago2 time2 tz2
size
num_creators
num_other_creators
main_creator
main_email
creator
name
date
summary

and optionally "version", "is_missing" and "filepath" if applicable 👑

this method implicitly calls rebunch with no parameter if new revision descriptions were added that are not bunched yet. it's proactive like that 💅

⭐ clear

clear all bunches and their revision descriptions 🧹✨

⭐ reverse_revision_descs

effectivelly empty all revision descriptions (both old and new) and readd them in the reverse order 🔄

return the object — which means you can chain a get or rebunch method call. yes, same deal as before, we love consistency 🫶

⭐ versions

return distinct versions that participated in all bunches. return an empty arrayref if not applicable, i.e. if version is given in the constructor 💀

⭐ filepaths

return distinct filepaths that participated in all bunches. return an empty arrayref if not applicable, i.e. if revision descriptions have no filepath 🙈

---

💀 BUGS 💀

waiting for your reports. 👀 like, genuinely. the author is just sitting there. bestie, send the report.

---

👑 AUTHORS 👑

Mikhael Goikhman (migo@homemail.com--Perl-GPL/arch-perl--devel). a legend, fr fr.

---

🌈 SEE ALSO 🌈

for more information, see Arch::Tree, Arch::Log, Arch::Session, Arch::Library. go read them, they're all connected, iykyk ✨

---

and that's the whole page, bestie!! this one's from perl v5.20.2, dated 2005-02-21, and it's part of the User Contributed Perl Documentation — so go forth, bunch those revisions, and slay 💖🎀🦋