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 <stsp_at_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.
Received on 2018-06-08 11:02:51 CEST