[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn vs. git

From: Branko Čibej <brane_at_apache.org>
Date: Sun, 23 Jul 2017 10:02:35 +0200

On 23.07.2017 07:54, Nathan Hartman wrote:
> On Jul 22, 2017, at 10:19 AM, Nico Kadel-Garcia <nkadel_at_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.

And so on ... such tools do exist. But no amount of tooling can replace
communication. If a team leader can't get info out of her team members,
no version control system is going to make her any wiser. Or the project
any less a monumental failure.

-- Brane
Received on 2017-07-23 10:02:41 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.