[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:42:34 +0000 (UTC)

Ryan Schmidt <subversion-2010d <at> ryandesign.com> writes:

>
>
> On Oct 13, 2010, at 01:25, LiuYan 刘研 wrote:
>
> > I'm new to subversion. I used CVSNT before.
>
> Welcome!
>
> > 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:
> > - Should file A and B be commited separately?
>
> If the changes you made to A and B are related, commit them together. If they
are unrelated, commit them
> separately. In your commit message, described what you changed.

Nice, grouped commit.

>
> > - Should file A be commited more than once per day?
>
> If you make more than one logical / functional change to file A per day, then
yes; commit once per thing you changed.
>
> > - How to issue these commits when there's 1 single subversion user?
> > - How to issue these commits in team working project?
>
> I don't exactly understand the question, but every team member will have
their own working copy which they
> can update and commit independently as needed.
>

Sorry for my poor English and poor expression.
I mean I usually work in a small team, and projects are usually very simple, so
I want to know how team members collabrate with each other on subversion commit
in a large team/project. But please ignore this, now I know no matter how many
members in team, let subversion take care of auto merging, let member himself
take care of conflicts.

Thank you Ryan for your detailed explanation!
Received on 2010-10-13 21:43:26 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.