On Wed, Nov 28, 2018 at 6:42 AM Ahtesham Kazi <ahtesham.k...@gmail.com> wrote: > > Greetings, > > I have read that subversion does not allow deleting obsolete not required > data. > Is there a way we can fork from some point onwards ?
Kind-of sort-of. There's a lot of discussion in the Red Book and mailing list. To prune content, you'll be committed to switching to a new Buversion repository. Pruning in place is *dangerous*, it's one of the oldest requested features, and as best I can tell it's never going to happen. The fastest and simplest is to snapshot a working copy of the limited content that you want and make a new repository, with no history. That is least likely to include bulky content from commits that touched multiple branches. Second fastest, if your Subversion content is not complex or heavily dependent on svn: settings, is to use git-svn to import the desired branch and only the desired branch, apply "git gc --aggressive" to the git repo, and use "git-svn" to export it back up to an entirely new Subversion repository. This works surprisingly well, though it can get quite confused about "svn:keywords" and similar attributes. The trickiest is to do a dump, exclude, and reload into a new repository. That's better able to preserve the history, unsullied, with really good provenance of subtle tuning like "svn:keywords". But I've personally given up on the approach. Subversion is aimed at conserving history, and the history of embedding bulky content accidentally or embedding keywords or embarrassing software errors accidentally and very reasonably wanting them *out* of the repos is why I've used the other approaches.