#22 Sort out branches: toplevel of branches only contains user folders.

[Edmund Highcock]

The top level of branches is extremely messy, and it makes it complicated to add and remove branches. I propose:

1. We make a push to remove all old/dead branches.
2. At the top level of branches, all there is is a single folder for each developer. That way the top level of branches is always tidy and the branch tree can be managed by each user individually.

Here are the last changed dates of all folders in gs2/branches. I have highlighted candidates for deletion in bold.

Please comment. Silence will be interpreted as acquiescence!

accel_fft_shm_2016Last Changed Date: 2016-05-01 00:52:32 +0200 (Sun, 01 May 2016)
alphasLast Changed Date: 2016-09-23 15:25:51 +0200 (Fri, 23 Sep 2016)
apartestLast Changed Date: 2012-03-31 23:49:32 +0200 (Sat, 31 Mar 2012)
apartest2Last Changed Date: 2015-02-04 11:42:43 +0100 (Wed, 04 Feb 2015)
AVOID_Type_Bound_Procedures_FixLast Changed Date: 2016-11-13 05:18:54 +0100 (Sun, 13 Nov 2016)
BugFix55Last Changed Date: 2016-04-19 10:14:42 +0200 (Tue, 19 Apr 2016)
BugFix_40Last Changed Date: 2015-09-02 18:42:00 +0200 (Wed, 02 Sep 2015)
cm_mergeLast Changed Date: 2010-02-03 15:20:24 +0100 (Wed, 03 Feb 2010)
cmrbranchLast Changed Date: 2010-08-12 23:54:06 +0200 (Thu, 12 Aug 2010)
convergenceLast Changed Date: 2014-02-26 14:13:33 +0100 (Wed, 26 Feb 2014)
dgLast Changed Date: 2013-12-10 15:58:27 +0100 (Tue, 10 Dec 2013)
eCSEworkLast Changed Date: 2016-06-14 18:23:09 +0200 (Tue, 14 Jun 2016)
eghLast Changed Date: 2015-09-23 18:00:18 +0200 (Wed, 23 Sep 2015)
eigUserTarget6.0rcLast Changed Date: 2015-04-08 09:41:34 +0200 (Wed, 08 Apr 2015)
exb_shear_jumpsLast Changed Date: 2015-02-11 12:48:59 +0100 (Wed, 11 Feb 2015)
fft_mpi3_2_LALast Changed Date: 2014-05-05 16:20:39 +0200 (Mon, 05 May 2014)
fft_mpi3_LALast Changed Date: 2014-02-10 19:57:11 +0100 (Mon, 10 Feb 2014)
fft_shm_LALast Changed Date: 2014-02-10 18:35:43 +0100 (Mon, 10 Feb 2014)
FixFileNameAndLocation_bug38Last Changed Date: 2015-04-09 16:30:30 +0200 (Thu, 09 Apr 2015)
gs2_sfincsLast Changed Date: 2016-12-07 04:37:54 +0100 (Wed, 07 Dec 2016)
heatingLast Changed Date: 2012-05-08 18:13:47 +0200 (Tue, 08 May 2012)
hybridimplementationLast Changed Date: 2014-07-28 16:08:02 +0200 (Mon, 28 Jul 2014)
intentsLast Changed Date: 2015-02-11 14:58:25 +0100 (Wed, 11 Feb 2015)
legacy-geo-branchLast Changed Date: 2008-05-27 00:28:10 +0200 (Tue, 27 May 2008)
les_layoutLast Changed Date: 2016-12-15 18:35:16 +0100 (Thu, 15 Dec 2016)
LowmemLast Changed Date: 2015-01-07 10:51:54 +0100 (Wed, 07 Jan 2015)
mb_branchLast Changed Date: 2012-02-13 18:29:33 +0100 (Mon, 13 Feb 2012)
MHardmanLast Changed Date: 2016-01-20 15:53:07 +0100 (Wed, 20 Jan 2016)
mrhLast Changed Date: 2017-01-03 18:08:41 +0100 (Tue, 03 Jan 2017)
nag_profilingLast Changed Date: 2016-05-18 18:31:33 +0200 (Wed, 18 May 2016)
nltweakLast Changed Date: 2015-01-26 13:18:44 +0100 (Mon, 26 Jan 2015)
nonmaxw_mergeLast Changed Date: 2016-12-09 16:42:14 +0100 (Fri, 09 Dec 2016)
normalisationsLast Changed Date: 2015-02-10 13:15:19 +0100 (Tue, 10 Feb 2015)
oldtrunkLast Changed Date: 2009-09-24 00:04:40 +0200 (Thu, 24 Sep 2009)
pjk_impgs2Last Changed Date: 2013-09-09 11:00:10 +0200 (Mon, 09 Sep 2013)
reinit_mpiLast Changed Date: 2013-10-01 17:18:08 +0200 (Tue, 01 Oct 2013)
shm_accelLast Changed Date: 2015-11-03 17:13:35 +0100 (Tue, 03 Nov 2015)
shm_mpi3_LALast Changed Date: 2014-02-10 18:32:15 +0100 (Mon, 10 Feb 2014)
single_kpar_modeLast Changed Date: 2011-07-04 11:58:01 +0200 (Mon, 04 Jul 2011)
single_restart_fileLast Changed Date: 2013-04-05 16:24:31 +0200 (Fri, 05 Apr 2013)
split_domainLast Changed Date: 2014-12-19 13:39:25 +0100 (Fri, 19 Dec 2014)
test_merge_shm_jun2016Last Changed Date: 2016-06-22 17:43:56 +0200 (Wed, 22 Jun 2016)
testlevelLast Changed Date: 2015-02-11 13:11:32 +0100 (Wed, 11 Feb 2015)
vpar_muLast Changed Date: 2016-12-21 18:33:28 +0100 (Wed, 21 Dec 2016)

[David Dickinson]

I think cleaning up old branches is a good idea, particularly ones that have been merged in, but of course sometimes people use these in a similar ways as tags (i.e. a fixed version that they wish to keep). I'm not sure if nesting actual branches inside another level fits well with standarad svn repos (which may complicate any future migration to git) but we could probably cope with this! I have tried to make branch names that clearly indicated the purpose (when I could remember) which hopefully made it easy to find fixes for bugs etc., this may become more complicated if they are hidden inside other directories, but again nothing vital.

[Edmund Highcock]

Hi David,

I think these are all good points, but I think they might be making the perfect the enemy of the good!

The current system would be OK if we all actually deleted branches all the time after they were no longer necessary. But we are all busy and we all have other things to do, hence the current crowded state of the branches repository. It makes adding and removing a branches a little more complicated, having to do finite-depth checkouts to avoid downloading every single branch etc, as well as having potential tree conflicts from large reorganisations of the branches folder. It also means that this flotsam and jetsam persists for a very long time, and we have branches belonging to people who may no longer be active contributors. If all the branches are grouped by branch creator, then it will be easy to move all the branches of a defunct contributor to an archive or delete them.

In response to your individual points:

1. If people want to keep branches as a tagged/saved state of the code but I think that should be a separate folder (I'll make a new one called archived_branches).
2. git-svn can be configured to deal with almost any branch structure, so I think that will be OK.
3. While in a perfect world with branch names that are easy to understand I agree that people would be able to dive in an out of specific branches if they wanted to contribute, in practice people very rarely contribute to other people's branches, so I think that having them in subdirectories will not be an issue (to deal with bugs maybe we should have a bugs subdirectory of branches that contains branches created purely to deal with specific bugs).

[Colin M Roach]

I am all for deleting branches, but I suggest that the originator of the branch (or someone who may have some memory or an interest) is asked to do this first! I will look at some of the branches that I was responsible for (e.g. cmr_branch) to remind myself what it was for and kill it if it has outlived its usefulness!