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

RE: Binary documentation in SVN?

From: Nick Seigal <nickseigal_at_iinet.com>
Date: 2005-02-15 22:00:06 CET

> From: Ben Collins-Sussman [mailto:sussman@collab.net]
> > It does, but to be honest (and no offense intended), this
> > just sounds like typical FUD against the CVS/SVN concurrency model.
> > Chapter 2 in the book tries to explain the difference between the
> > traditional lock-modify-unlock model used by VSS, compared to the
> > copy-modify-merge model. I don't want to repeat that section here,
> > but go take a look at the major points in there, if you haven't
> > already.

I have read it several times and thought a great deal about what it says
(and doesn't). I don't know what a "FUD" is, but if my question was
"typical", then it would have been answered in the FAQ and I wouldn't have
asked it. If Ben is saying "RTFM", then I think he has missed my point.

> > ... If you really have two developers working on
> > fixing the same bug at the same time, then you have bigger problems
> > to worry about. :-)
> > We're not striving to become a universal communication
> > system -- that's what email, IRC, bugtrackers are for.

I don't dispute that I guess, but all the tools can help by working
together. The info I want is Subversion commit activity and would need to
come from Subversion. This is not going to be found in email, IRC, etc.
without some serious work and/or dedication to a process that captures all
the commit info manually. Bugtrackers will show info on closed tickets and
possibly progress towards closing, but not bytes-comitted or number of
commits per day, etc. These metrics coulkd be very useful IMHO.

> > (That said, 'svn status -u' *will* show you which files have changed
> > in the server, so you can predict merges and conflicts before you run
> > 'svn update'.)

Yes, and if it also showed *how often* the files had changed, *how much*,
and *by whom* (i.e. commit-activity by user) that would be even better! ;-)

I understand that isn't the SVN dev team's priority. I guess that when/if I
get my tool written that does this, I will see how useful (and popular) it

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Feb 15 22:02:52 2005

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.