On Mon, May 11, 2026 at 1:31 PM Daniel Sahlberg <[email protected]> wrote: > > Den mån 11 maj 2026 kl 03:50 skrev Nathan Hartman <[email protected]>: > > > > On Sun, May 10, 2026 at 2:55 PM Timofei Zhakov <[email protected]> wrote: > >> > >> > >> On Sun, May 10, 2026 at 8:03 PM Branko Čibej <[email protected]> wrote: > >>> > >>> On 10. 5. 26 19:13, Daniel Sahlberg wrote: > >>> > >>> Hi, > >>> > >>> We have quite a lot of branches in > >>> https://svn.apache.org/repos/asf/subversion/branches/, some very > >>> active (javahl-1.15 for example), some that have been merged to trunk > >>> (cmake, swig-py3) and some that are unlikely to even be merged > >>> (scons-build-system). There are also obsolete backport branches > >>> (1.7.x-sqlite-3.12) that are nominated but not merged and where the > >>> corresponding release line is closed for further changes. There are of > >>> course also interesting branches (svn-bisect) that may contain > >>> interesting ideas. > >>> > >>> Do we have a policy for removing branches when they have served their > >>> purpose or when they have reached a dead end and are unlikely to see > >>> further work? I'd like to propose to clear out at least the branches > >>> that are unlikely to be merged, to make it easier to find the valuable > >>> ideas. > >>> > >>> > >>> We don't have a policy as far as I can remember. I'd lean towards keeping > >>> the branches there; they're not using extra space in normal checkouts or > >>> anything. If it's a question of keeping things tidy and especially > >>> helping people know which work is "current" for-some-definition-of and > >>> which is obsolete, we can create another directory in the tree in > >>> parallel with trunk/branches/tags – that structure is supposed to help > >>> us, not bind us, after all. > >>> > >>> So for example, we could move > >>> > >>> branches/1.7.x-sqlite-3.12 > >>> > >>> > >>> to > >>> > >>> inactive/1.7.x-sqlite-3.12 > >>> > >>> > >> > >> The only issue with this approach is that some tools (like git-svn that > >> makes our github mirror) expect normal branch layout with branches/ tags/ > >> and trunk/. Of course they usually allow for a change but sometimes it's > >> annoying to maintain. > >> > >> Also I like the style where the release branches (like 1.15.x) are located > >> in the 'stable/' directory instead of 'branches/'. > >> > >>> > >>> or something like that. It's true that the history always remains. It's > >>> also true that data that's not indexed is hard to find. So, keeping > >>> visible pointers to that work might well help someone in the future and > >>> it doesn't hinder or constrain us in any way. > >>> > >>> -- Brane > >>> > >>> > >>> P.S.: On the other hand, I intend to delete the javahl-1.15 branch after > >>> it's merged to trunk. > >>> > >> > >> > >> -- > >> Timofei Zhakov > > > > > > > > I agree that the branches don't take up disk space. In my mind, an argument > > for removing (or moving) them is to clean up clutter that adds to our > > cognitive load. > > > > There are four types of branches mentioned here; each deserves a different > > treatment: > > > > * active - obviously we won't delete those! > > > > * work-in-progress, e.g., experiments, ideas, features, like > > scons-build-system or svn-bisect - these are interesting even if stalled > > and incomplete. Some of these could get picked up in the future. IIRC > > that's what happened with Multi-WC, which lay dormant for some time and is > > now an important feature of 1.15. Even when this doesn't happen, these > > branches may be valuable for reference. I recommend to keep them exactly > > where they are. > > > > * completed and merged to trunk - Normally these should be removed after > > merging, I think it's a little bit confusing to keep them around because > > it's unclear why they were kept. Intended as long-lived branches? For > > bisecting purposes? To document the development timeline of a feature? > > Modifying Brane's idea, these could be moved to a new 'merged' subtree. To > > Timofei's point about the bridge to git, we certainly wouldn't want active > > or in-progress branches to disappear from git, but in this case where the > > branches were already merged, their disappearance after merging is typical > > of most common git workflows, so I think it would be okay. > > > > * backport nomination branches that were never approved for EOL release > > lines: I wouldn't feel too bad about deleting them, but if we do, we > > probably should clear the nominations from those EOL branches' STATUS, to > > remove dangling references. > > > > Of course, this all translates to time and effort to study each branch and > > figure out its story. :-/ > > > > Cheers, > > Nathan > > > > Thank you all for the valuable input! > > What I'm after is to reduce the cognitive load of: > - Branches that no longer needed (I believe Timofei recently > (r1934075) deleted windows-shared-ra-modules for this reason). > - Branches that have been superseeded by other work (I think it is > extremely unlikely that we would switch all builds to scons so while > scons-build-system might be interesting, we won't loose anything if it > is not immediately visible). > > I agree that some branches may come back after a long time so we > should be very careful removing anything based on the the second > criteria.
I think this kind of branches should never be deleted for a reason that there were people that took their time to try out an idea they had, but for whatever reason, that work has never been merged into the trunk. Even if the idea itself is outdated, it's an experience that happened to the project. Whenever someone else in the future suggests adding scons, they'd find (or somebody else would link) a related branch which I think is always a cool thing. I know that they are still present in the history, but it's much nicer to see all of that listed in ^/subversion/branches/. For example I, as a person who joined the community not that long ago, could investigate all those abandoned ideas right in the repository. > I spend this time and effort whenever I'm in "branches" looking for > something (just by downloading BRANCH-README) so if I spend a few > additional minutes to send a suggestion to dev@ and save someone else > that time later on, it is time well spent. > > Cheers, > Daniel -- Timofei Zhakov
