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

Re: Logging granularity

From: <cmpilato_at_collab.net>
Date: 2003-05-16 02:19:50 CEST

"maru" <maru@mobile.rogers.com> writes:

> Beyond implementation challenges or bad cvs memories, the exclusion
> of per-file logging from svn appears to be largely one of svn
> developer preference. Logging granularity is clearly a religious
> issue - I wish I had realized this earlier. There is little I can
> do to pursuade die-hard fans of revision-only logging that per-file
> logging has any merit. There is little you can do to convince me
> that bad experiences with one revision system - cvs - justify the
> exclusion of per-file logging from svn. I hope we can just agree to
> disagree on this. I'm sure you have better things to do than argue
> with feature-whiners such as myself.

Well, don't write the idea off yet. I'm not going to propose that we
jump to support per-file logging now, but you might find it
interesting to note that our model certainly *supports* per-file
logging.

1. Teach your developers that any time they make a change to a file
    or directory, they must edit a 'last-changelog' property on that
    file or directory.

2. Write a pre-commit hook to verify that every path changed as part
    of a commit also has a new value for this property.

3. Write some scripts to help you extract the value of that property
    for each revision of the file or directory, and display those
    value in an 'svn log'-like format. For example, you can have a
    script that runs 'svn log -v', and then for each path of each
    revision, fetch the 'last-changelog' property and display it in
    whatever way you so desire.*

We may not do the dirty work for you pre-1.0 (or ever, for that
matter), but if this is the only thing keeping you from a love affair
with Subversion, you might want to go ahead and "slip into something
more confortable". ;-)

(*after we get the generic remote 'svn propget' functionality in
  place, currently unfinished)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 16 02:25:04 2003

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.