[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: William Moss <WMoss_at_ajc.com>
Date: 2003-05-16 22:29:33 CEST

>Benjamin Pflugmann <benjamin-svn-dev@pflugmann.de> wrote:
>>>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.
>
>That's funny, because exactly the fact that I already followed that
>practice with CVS is the reason why I also want these per-item logs.
>(the CVS logs are more similar to per-items logs than per-commit logs
>when CVS is used this way).

I've followed this thread from a slightly different perspective. I like
the svn practice of per-commit logs to encourage one conceptual change per
revision, but I'm interested in a meta-commit log to explain what's going
on over a series of very tightly related revisions.

Say I'd divided my project into a model-view-controller architecture and I
wanted to make a huge structural change impacting all three areas. How
would I do something like this in svn?

a) make 1 commit with all changes and log the structural "why" as well as
the M-V-C "how"
b) make 3 commits with changes and logs for the M-V-C "how" and repeat the
structural "why" log each time.
c) make 4 commits
   1) add /* todo: structural changes coming */ comments in effected
files; commit with "why" in log
   2-4) remove todo comments, make code changes, commit to log the "how"
in effected files.

Option a isn't a big pill to swallow especially if part of the M, V, or C
has to be rolled back.
Option b has the problems inherent with repeating data over and over again
(and maybe having it change accidentally or purposefully each time)
Option c means that you know what files are involved before starting the
real changes (something I'm not so good at)

I admit, I'm pretty poor at using any version management software so this
very well could be something much more easily dealt with. But this latest
argument triggerd my question because this seems like the same situation
as the per-file / per-commit argument but one level higher (if you get my
drift).

Waiting to be shown the complete stupidity of my way.

William
Received on Fri May 16 22:30:46 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.