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

Re: Best practices log messages early in development

From: Bryan Donlan <bdonlan_at_gmail.com>
Date: 2005-01-14 19:35:55 CET

On Fri, 14 Jan 2005 12:07:28 -0500, Martin J. Stumpf <mjs@jhu.edu> wrote:
> Hello everyone,
>
> I am struggling with best practices with log messages early in the
> project life cycle.
>
> The problem is that I may work non-stop for 8 hours on a project and
> touch a dozen files. With each class in its own src file and headers, I
> often need to make many modifications as the API evolves. The problem
> is that I don't want to commit too early because I know in my head what
> design requirement I am implementing in this work session and I am 'not
> finished yet' with the current coding objective. By the time I reach my
> goal, implement that particular design requirement, I can no longer
> think/remember what specificaly was done in each file.
>
> I don't want to use a global log message because that doesn't make the
> log history very helpful. It isn't always a case where all the changes
> fit nicely under the message that may correctly belong to the file that
> receieved the bulk of the editing. Are you following me? I hope I am not
> the only one who struggles with this. I build and test during this work
> session and often make other changes.
>
> Maybe I should be committing more frequently. Maybe I should create log
> message files. With the latter, the daily commit becomes laborious.
>
> What do you guys do to make the log really helpful on large projects?

You could create a branch, make individual commits there, then merge
it to trunk with a note indicating the old branch, and what you did
overall.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jan 14 19:42:00 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.