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 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
