subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Hartman <>
Subject Re: svn vs. git
Date Sun, 23 Jul 2017 05:54:17 GMT
On Jul 22, 2017, at 10:19 AM, Nico Kadel-Garcia <> 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 :-)
View raw message