I guess an alternative would be introducing an attic area under branches/tags that you make a copy of the entire trunk in at the point just before removing a particular component, thus giving a single place to point people at if needed and keeping a suitable record of whats removed when. Best of both worlds?
On 1 April 2011 15:23, Robbie Gemmell <[email protected]> wrote: > True enough, if you know its there...it does mean that in future as things > get sent to the attic you would need to know when it happened in order to > find the code again as there would be no single place you might expect to > find such things. Going with /attic achieves the 'remove it from trunk' goal > just as effectively, without making life difficult for anyone who > wants/needs to go looking for such things in future. > > For what its worth, the above route is also how many sites operate their > sandbox environments etc and so would match up well with things like that > (yet another discussion...) > > Robbie > > > On 1 April 2011 15:11, Gordon Sim <[email protected]> wrote: > >> On 04/01/2011 03:10 PM, Robbie Gemmell wrote: >> >>> By deleting, it becomes more of a pain for people to >>> inspect the old code (which they may actually be using a version of even >>> if >>> we don't support it) or create patches against it etc should they want to >>> without actually reviving the whole lot back to trunk. Things may never >>> be >>> truly deleted from the repo, but 'deleting' them does make it more of a >>> pain >>> to ever do anything with it again. >>> >> >> The code will still be available on release branches. So e.g. in this case >> the 0.8 release branch will have the 'last released' code for those >> components, and should be as easy to read as it would in an attic... >> >> >> --------------------------------------------------------------------- >> Apache Qpid - AMQP Messaging Implementation >> Project: http://qpid.apache.org >> Use/Interact: mailto:[email protected] >> >> >
