On Sun, Jul 23, 2017 at 4:02 AM, Branko Čibej <brane_at_apache.org> wrote:
> 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.
Oh, this is getting into development philosophy and practices. The
team leader may not *care* about this information, it may only be the
concern of developers whose work overlaps with that of the secretive
developer. Or the team leader may be the sinner who refuses to commit
their work because "it's not ready for release" or "not ready for
review", and causes compatibility branches with either subversion or
git. I've had good success with git encouraging developers to clone
their own personal repository up at github, making their changes to
branches there, and leaving them visible to see the day's work. But
good workflow, whether with git or Subversion, is hardly the only
reason a project can fail or even succeed despite poor source control
practices.
I've even seen some principal developers, especially those titled
"architect", who keep their work offline before they publish it
because no one else *does* understand it, and burning the time
educating them would make everyone miss release dates. I've even been
hired to clean up after years of that kind of practice, especially
coupled with "I don't document, if you have a question just ask" and
"the actual code is the only possible documentation, comments just
lead to confusion". It's an art form.
Circling back to the original point. Local commits for Subversion,
effectively transforming it to a DVCS or distributed version control
system, could be very cool. I'm concerned that it would eliminate one
of the features most critical to Subversion, forcing all commits to be
recorded on the central repository. If it's some intermediate solution
with new technologies and workflows, I'm uncertain of the benefits
when git-svn works reasonably well.
Received on 2017-07-23 22:21:37 CEST