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

Re: Case study: Mono switches to Subversion

From: Daniel Rall <dlr_at_collab.net>
Date: 2004-11-18 00:27:07 CET

On Wed, 2004-11-17 at 11:16 -0600, Ben Collins-Sussman wrote:
...
> But the two lead developers absolutely refuse to give it up; the
> critical issue, I'm told, is that they want the whole Changelog to be
> available offline at all times.
...
> So, no action item here -- just a mental note for future projects.
> You may run into resistance trying to persuade them to drop
> 'Changelog'... especially really huge projects.
...
> The moral of the story here? There are people out there who refuse to
> leave the "every file is an island" universe. Maybe it's a holdover
> from RCS days, I'm not sure. Be prepared to meet such people.
...
> 4. In general, I think our own view of version control has become a
> bit skewed toward small communities. If we want projects like
> GNOME to switch, we may have to investigate some time in
> redesigning our 'svn blame'.

Though community size and composition plays a factor here,
realistically, a large portion of what Ben describes above is human
nature's -- or even nuture's -- resistance to change. People don't like
to change their habits, sadly, even to change for the better (like more
efficient development habits). When people change tools, they want new
functionality without adjusting their working style to accommodate the
tool -- they want the tool to accommodate _them_. This is not an
entirely unreasonable request! With strong personalities like those
found in corporate and community leadership, I've often noticed this
condition to be magnified.

Given that resistance to change being found in the majority of people,
and an heavily "archaeological" development community is the norm for
most companies due to engineer turnover and not at all unheard of for
community-based projects (as described by Ben for Mono and GNOME), I ask
you: How do you characterize Subversion's set of target groups of
users? How do you prioritize delivery of features to entice each user
group?

Personally, I am strongly biased towards my own selfish development tool
needs, which closely align with the current trajectory of this project
(we all like to scratch that itch). However, if it's possible to
capture much larger groups of users with minor adjustments to the
trajectory, I'd not want to discount in-flight course corrections.
What's always been a bit of mystery to me is how to accomplish those
course corrections without a loss of motivation...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 18 00:27:27 2004

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