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

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

From: LiuYan 刘研 <lovetide_at_21cn.com>
Date: Wed, 13 Oct 2010 19:05:52 +0000 (UTC)

David Weintraub <qazwart <at> gmail.com> writes:

>
> 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.

BTW, CVS tagging is very nice, 'tagging' (svn copy) in subversion is like an
extra commit and result in a new revision, although 'svn copy' is a light/cheap
way in subversion, it still make me confused sometimes.

I remember there's feature request about this, maybe called 'labeling' or
something like that, wish it can be implemented in future subversion version.

>
> 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.
>

Thank you David for your detailed explanation!

I will grouped-commit changes now, and I should not afraid of many revisions. :)

It's time to convert my CVS repository to SVN repository. :D
Received on 2010-10-13 21:06:40 CEST

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.