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 >> inhttps://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
