The only one I'm strongly opposed to is #4. I slightly prefer #3 of the remaining options. It gets the old content out of the way without deleting it.
> -----Original Message----- > From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com] > Sent: Monday, March 09, 2015 12:25 PM > To: users@qpid.apache.org > Subject: handling old Subversion contents after migrations to Git > > Hi all, > > As you probably know, we migrated the Proton and new JMS client code to > Git repositories last year. As part of the process the old locations within > the > Subversion repo were frozen read-only and left in place. > > Some folks have been caught out by using the old stale locations, as although > we have updated our website with the new locations (and all the commits@ > traffic mentions the new locations) it isnt particularly clear from the old > contents themselves that they are no longer in use (other than by realising > the last commits were a while ago). > > I noticed some documentation which indicated as Chair I should be able to > modify the access rights to the old locations, allowing us to edit them and > make things clearer. I checked with infra and that is indeed the case, > although they are also happy to do it for us depending on the change (e.g > move contents to an attic dir, add pointer file). > > I wonder what people think we should do: > 1. Add pointer files indicating the contents are no longer used and directing > to the Git repos. > 2. Delete the trunk dirs, add pointer files to the Git repos. > 3. Move the contents to an attic area, add pointer files to the Git repos in > old > locations. > 4. Delete the contents entirely, dont add pointers. > > (The 'deleted' files will obviously remain in Subversion history) > > Thoughts? > > Thanks, > Robbie > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional > commands, e-mail: users-h...@qpid.apache.org
