Re: Need advice on when to commit and how many commits to issue when multiple files changed

On Wed, Oct 13, 2010 at 2:25 AM, LiuYan 刘研 <lovetide_at_21cn.com> wrote:
> Hi all,
> Because a single svn commit will result in a whole new revision tree, so
> currently I commit all changes once per day after work (to avoid too many
> revisions because of my old CVS habit).
>
> But I'm afraid it's not a proper way, so:

Commits should be done as part of a set of changes. Think of it this
way, you are repairing Bug #123, and to do that, you have to modify
four files. Those four files and only those four files should be
committed together as a fix for Bug #123.

This way, if there is some reason to back out this change, it is easy
to locate and do. One of the biggest reasons to use Subversion over
CVS is when it comes to backing out a change.

In order to backout a change in CVS, I first have to find all of the
files changed which can be difficult. In CVS, all files are versioned
separately. Doing a cvs log is unwieldy. It's one of the reasons we
would tag after each CVS build.

In Subversion, an "svn log" will allow me to quickly find the change
and all files changed. Backing it out is a simple matter of a
subtractive merge between the HEAD and the revision you want to back
out.

Don't worry about too many revisions. Subversion can easily handle
them. Instead, think about checking in files as a related group --
they fix a particular bug or implement a particular feature. That way,
it's a lot easier to see what was changed and why.

-- 
David Weintraub
qazwart_at_gmail.com