Daily bruteforced SVN commits

LanX has asked for the wisdom of the Perl Monks concerning the following question:

I got the requirement to fix a script which automatically commits a huge list of regex-matched files into SVN on a daily basis.

My clients idea is that he can't trust his "programmers" to do it manually. (please don't ask)

The Perl script is rather messy, uses run3 to call CLI commands and regularly fails on locked files from interrupted commits("cleanup" necessary) or time stamp conflicts (i.e. someone copied an older version in place) and other things.

I'm wondering if someone already solved this requirement in a reliable way, preferably on CPAN, helping me to avoid reinventing a wheel or fixing this polygonal pseudo-wheel.

FWIW: I already suggested to additionally use GIT for skilled disciplined developers!

Please avoid bashing me for the requirements of my client... ;-)

Cheers Rolf
_{(addicted to the Perl Programming Language and ☆☆☆☆ :)

Je suis Charlie!}

Comment on Daily bruteforced SVN commits

Replies are listed 'Best First'.
Re: Daily bruteforced SVN commits by ExReg (Priest) on Jul 05, 2016 at 18:46 UTC
Not sure if you have searched the monastery yet, but RFC: Automating subversion with perl seems to have some good info.	[reply]
Re^2: Daily bruteforced SVN commits by LanX (Saint) on Jul 05, 2016 at 23:51 UTC
No I haven't searched the monastery explicitly, normally google is pretty good in digging them out. (probably I was only relying on DDG, though.) This post looks interesting but as far as I was able to decipher between all the HTML errors, it's mainly describing the API of Alien::SVN and not how to enforce a commit. Anyway I had an interesting chat with TomFahle on our local PerlMongers meeting and he had once a similar project. In his opinion Tortoise SVN is pretty messed up and my only chance be identify all conflicting files with `svn cleanup` moving the conflicts safely away running `svn up` to get the old (conflict free) versions reestablished moving the files back overwriting the old versions again while losing the conflict now commiting Haven't tested this approach yet, but it sounds promising. :) Cheers Rolf _{(addicted to the Perl Programming Language and ☆☆☆☆ :) Je suis Charlie!}	[reply] [d/l] [select]
Re: Daily bruteforced SVN commits by perlfan (Parson) on Jul 06, 2016 at 14:56 UTC
Not sure of the current state, but have you looked at svk? It's written in Perl but uses and extends Subversion's file system/hierarchy. https://en.wikipedia.org/wiki/SVK#Features.	[reply]
Re^2: Daily bruteforced SVN commits by LanX (Saint) on Jul 06, 2016 at 15:59 UTC
This really looks very interesting, thanks. :) But I can't see how it helps forcing automatic commits to SVN and my client will reject a framework for this singular task. Thanks anyway! =) Cheers Rolf _{(addicted to the Perl Programming Language and ☆☆☆☆ :) Je suis Charlie!}	[reply]
Re: Daily bruteforced SVN commits by KeighleHawk (Scribe) on Jul 08, 2016 at 22:22 UTC
Do you have any latitude/leeway on the svn repository arrangement? Can you rearrange it? If so, you might consider getting everyone to check in to the trunk once, cleanly, then make a private developer branch for each developer. Then "close off" (by convention) development on trunk. If you can do that, then everyone develops in their own branch, so no more conflicts. Trunk is then used only to periodically merge the developer branches. Generally, this will be followed by tagging it and then probably pushing back to the developer branches. Up to you if you want a convention of periodic tags vs. tested and known stable tags, but that's just a naming convention. Obviously, someone gets the unlucky job of SCM/Build Master to manage trunk and tagging. With some education, you may be able to push back on the developers to keep their own development copies in sync, or brute more force by just giving them a new copy of the latest tag. It's almost like git, the hard way (and no actual local copy of the repo...)	[reply]
Re^2: Daily bruteforced SVN commits by LanX (Saint) on Jul 09, 2016 at 16:54 UTC
Thank you for these very good ideas... but > Do you have any latitude/leeway on the svn repository arrangement? Can you rearrange it? I wished, I am struggling to prevent some people to change things directly in production. :/ Cheers Rolf _{(addicted to the Perl Programming Language and ☆☆☆☆ :) Je suis Charlie!}	[reply]