[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: maru <maru_at_mobile.rogers.com>
Date: 2003-05-15 23:33:19 CEST

So out of curiosity, is svn targetted only at making a better cvs? I thought the idea was to make something truly world-beating. It's a solid, well-designed application. You harp on how much better its approach is to cvs. But why set your benchmark so low? Why not acknowledge that the real target is to match best-of-breed tools like bitkeeper or perforce? Subversion has the potential to be the _best_ scm, not just the best _free_ scm. If your only example is cvs, I'd say pretty much anything would impress you.

-----Original Message-----
From: Brian Denny <brian@briandenny.net>
Date: Thu, 15 May 2003 14:23:03
To:Branko ??ibej <brane@xbc.nu>
Cc:maru <maru@mobile.rogers.com>, dev@subversion.tigris.org
Subject: Re: Logging granularity

On Thu, May 15, 2003 at 08:54:26PM +0200, Branko ??ibej wrote:
>
> One of the reasons why we only have per-commit logs is to, let's say,
> "edcate" users to group logically related changes into a single commit,
> and use separate commits for different changes. If you look at
> Subversion's own commit log, you'll see that we follow this guideline
> 99% of the time; so the logs describe a changeset, and descriptions of
> changes to indivitual files in the changeset come naturally from there.
> They aren't frustrating at all.

Just to second Brane's point -- I never used to follow this practice with
CVS, and now, using Subversion I am a total convert. In combination
with the global revision numbers, the practice makes it so easy to merge
or otherwise transport changes from one codeline to another.

Also, having one message per global revision makes it so, so much easier
to find what you're looking for when you run 'svn log' on a whole tree,
as compared with CVS where you get tons and tons of output since each
file has its own logs.

-brian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 15 23:44:41 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.