On 08.06.2018 10:20, Doros Agathangelou wrote: > Another option is to use Subdivision, a commercial tool that is > designed to do exactly these kinds of operations, in other works > Delete files, Extract files, Split repositories in two parts. > Subdivision reads the repository structure in memory and 'understands' > the structure of your repository. It can therefore create the > necessary derived selections from your selections to make sure that > the delete operation succeeds in the first pass. In this example, > Subdivision would make sure that /branches/develop/dir2 would be > available for the copy to be made from it (or that both source and > copy would both be unavailable - depending on the user selections). > > Subdivision is a Windows application but we are working on a Linux > solution too. You can try a demo by visiting http://subdi.vision > > Goes without saying that we are affiliated with Subdivision and we are > sorry for the shameless advertising but we believe people in this > group will benefit from knowing that Subdivision exists.
Before advertising proprietary, platform-specific tools, I'd first suggest that the OP take a look at https://gitlab.com/esr/reposurgeon which also supports these kinds of operations and is open source. > On Thu, Jun 7, 2018 at 6:08 PM Stefan Sperling <s...@elego.de> wrote: >> On Thu, Jun 07, 2018 at 10:40:51AM -0400, Alfred von Campe wrote: >>> Thanks, Stefan. The path of least resistance for me is to use the script >>> you pointed me to. However, it seems that the exclude feature is not yet >>> implemented: >>> >>> try: >>> if args[0] == 'include': >>> sys.exit(analyze_logs(map(sanitize_path, targets))) >>> elif args[0] == 'exclude': >>> usage_and_exit("Feature not implemented") >>> else: >>> usage_and_exit("Valid subcommands are 'include' and 'exclude'") >>> >>> Is there a more recent version of this script? >> I am afraid not. The link I provided points to the latest version of >> this script we have in our repository. We would welcome patches to >> the script. However, since the problem has been fixed in SVN 1.10's >> version of 'svnadmin' I think it makes more sense to just use 1.10. >> >> You could install 1.10 binaries somewhere next to your existing SVN >> installation and use the 1.10 svnadmin binary to create a dump file. >> The resulting dump file will be compatible with older versions.
