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
