RE: help me show others that there are valid reasons for not supporting a $log$ keyword!

> From: Steve Povilaitis [mailto:stevepov_at_gmail.com]
> Sent: Tuesday, September 16, 2008 9:33 AM
> To: users_at_subversion.tigris.org
> Subject: help me show others that there are valid reasons
> for not supporting a $log$ keyword!

> Our program management is clamoring for including a
> revision history like the old cvs $log$ keyword at the
> beginning of every file. I know there are good reasons for
> not supporting a $log$ keyword or even the idea of
> including a running log in the file, but if I'm not able
> to make a case for abandoning the idea, I'm going to be
> forced into writing some sort of kludgy script to do just
> that.  I've searched previous posts explaining why this is
> a bad idea and this is my understanding of some of the key
> points:

Turn the question around. What are the benefits of putting the log history in each file?

What is the goal/purpose/benefit of the log? If SVN can provide or meet that goal/purpose/benefit, then it shouldn't matter how it's implemented. Don't force the Old Inefficient Ways on New Tools. There's a reason why automobiles are not equipped with buggy whips, and why horse buggies don't have air conditioning, headlights, turn signals, airbags, and anti-lock brakes that can safely stop two tons of metal going 60+ miles per hour.

Paradigm shift. As others have pointed out, SVN logging on a per file basis doesn't make sense. CVS *has* to put the log history in each file because CVS is primitive and only manages change on per file basis (each file is a database object with its own history and version tree.) By comparison SVN manages change sets across multiple files and logs as a whole, instead of as a sum of the parts.

Make the transition easy. When you deliver code, simply run 'svn log' at the top dir and send that change log as a file in the package. You may also want to provide a tool/script to easily pull the revision history for individual files.

Plan B. Why are you delivering source code? SVN has a web interface. SVN repositories can also be accessed over the internet, which not only gives you logging, it also provides the ability to do diffs! $log$ *assumes* that you use accurate and meaningful comments. Diff'ing lets you see what really changed. IIRC, SVN 1.5 also supports replicated repositories.

> 2. Having a large block of text at the front of the file
> is unwieldy and confuses external diff tools.
> 3. It messes up binary files
> 4. Possible merge conflicts

In other words, $log$ lowers code quality...

Finally, $log$ is *not* a replacement for a proper changelist or a ticket list. $log$ isn't guaranteed to be accurate, nor is it organized, and most importantly, test cases aren't run against $log$. Test cases are run against tickets, change sets, features, or requirements, which is the information that should be used to create a proper, accurate and useful changelist.

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-09-16 17:58:10 CEST