On Jul 22, 2017, at 10:19 AM, Nico Kadel-Garcia <nka...@gmail.com> wrote: >> I can glance at it if I can find some cycles, no promises. I'm leery: > much of Subversion's support that I've seen, and that I've sold > Subversion migration work with myself, is that the singular repository > can be used to force developers to commit their work daily, to gather > some idea if they're actually working on their projects, and avoid > them squirreling away their work without code review or consistency > checks against the main development branch. Been there, done that with > personnel keeping git branches on their personal laptops or personal > VM's and being horrified with later merges or even with what I found > out they were doing later. It's enormous fun when an employee says > "I've already done that" but somehow has never published their code > anywhere that other people can see the work.
That's a legitimate concern. It could be partly addressed by adding an analytics feature. That's a buzzword and could generate some hype as a side benefit. There are already plenty of "analytics" features in Subversion (like blame) and perhaps what's needed is a python script that looks at the last day, week, and month, and spits out a report on how much and how often each user has contributed in those time frames. Perhaps it could calculate ratio of time between commits to combined size of patch plus log message, to try and ascertain if someone is actually committing their work. That's just an example to illustrate. I'm not saying it actually makes sense -- I know that you could spend weeks tracking down a one-character bug. And yes this comes with every imaginable caveat not least of which is that users will play the system if they know what their boss is measuring, but as a project manager you understand that this is a human problem and a management challenge and not something that technology can solve for you. What technology can do is number crunch to sort out the data and help you detect potential problem areas. As an argument in favor of local shelving and checkpointing, while git-svn is perfectly legitimate, git is heavy artillery and git-svn requires working with and understanding both systems. That's okay for some people but others would like to stay within Subversion. It reduces various barriers to entry. If done well it would be opt-in, meaning that you would use Subversion exactly as before, but if you want the local features, they'd be there for you. That said, one idea I floated at dev@ was that "svn up" could automatically make an implied checkpoint before updating, so that you'd be guaranteed never to lose anything should incoming changes mess up your work. That fits well with Subversion's overall concept in my opinion. Just my 2 cents :-)
