On Tuesday 03 May 2005 21:08, John Burwell wrote:
> On May 3, 2005, at 7:31 PM, John Szakmeister wrote:
> > Perhaps, not keeping it a secret would be a good thing? See if
> > they'll
> > mind if you create a repository and start using it. Perhaps they
> > might
> > be interested in how well things are working. :-)
>
> Hmm, you make a good point.
>
> Part of the issue is the perceived effort required to get started.
> While I think everyone believes we badly need this, the schedule is
> always such that there's no time for much besides the daily
> emergencies.
I would recommend doing the up-front work of getting a repository set up,
and demonstrating the features (run through a daily use sort of
scenario). Show the commit mails, perhaps use Trac (which has a built-in
source code browser, issue tracker, and wiki), and show how it all can
help in your daily environment. If you have a small project that you can
import and show, that would be a great starting point.
> Doing it on the sly initially will enable me not only to keep track
> of their changes for them, in case of ... well, emergency, but also
> to have some demonstrable material immediately available when the
> time comes to make another pitch.
But the problem is that you only know what *you* are putting into the
repository. If you blindly commit everyone else's code at the end of the
day, neither you nor your teammates knows what it is. It makes it much
more difficult to fall back to a known good state (Did the code in the
directory work? Were they in the middle of something? What changes did
they make?). Some amount of diff'ing will help, but that only ruins the
perception of version control, because it didn't make it easy to fall
back to a known good state. And what about added files, removed files,
and renamed files? The svn_load_dirs.pl script can help with this to a
degree, but you lose a lot of valuable information without the user
typing in commit messages about what they've done. IMHO, it can make the
difference between a good and bad version control experience.
> I also want to have a chance to get things set up so it's clear what
> it looks like on our real-world projects. If I can lay in a couple of
> ruts initially, it might help guide some of the exploration when it's
> released into the wild. Setting a good example and all that.
We have an environment that is very similar to yours (not much hierarchy,
and everyone brings a different set of skills to the table). Don't
underestimate what they can contribute though. The fact that you're
willing to set things up and make it go will most certainly go a long
way, and may encourage others to help. This was exactly the case when I
first introduced version control to the team. Two other guys stepped up
to the plate. One helped me to administer the server, and the other was
very interested in trying it. Over time, others came forward and I had
two other people around to help "train" them. It was slow, but it worked
out great. The two guys helped show more people on the team the benefit
of using version control than I could have done myself. It really helped
to speed adoption.
BTW, I'm not sure what you mean by "lay in a couple of ruts initially,"
but if it means to purposefully break something, don't do that. Enough
problems occur normally during development, there's no need to fabricate
anything. Besides, it damages the respect that you may have with your
peers. Doing it out in the open with a "daily use" demonstration (i.e.,
with them watching, commit something wrong and roll it back out) will go
much further than wasting someone's time and frustrating them with an
unknown error.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed May 4 11:47:08 2005