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

[LiuYan 刘研 <lo...@21cn.com>]

Hi all,

I'm new to subversion. I used CVSNT before.

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?
- Should file A be commited more than once per day?
- How to issue these commits when there's 1 single subversion user?
- How to issue these commits in team working project?

Any advice will be appreciated.

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

[LiuYan 刘研 <lo...@21cn.com>]

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!

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

[Ryan Schmidt <su...@ryandesign.com>]

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.

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

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

[David Weintraub <qa...@gmail.com>]

On Wed, Oct 13, 2010 at 3:05 PM, LiuYan 刘研 <lo...@21cn.com> wrote:
> David Weintraub <qazwart <at> gmail.com> writes:
> 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.

CVS does real tagging and not the "it's really a directory copy" crap
that Subversion does. However, Subversion takes less than a second to
tag, and tagging in CVS means each and every file must be tagged. That
can take a while. If you do continuous builds, and tagging in part of
a build, it could make a five minute build take 15 minutes.

Truthfully, tagging in Subversion isn't necessary because of the
revision numbers. Unless a site I work with really wants build tags, I
simply don't bother with them. Only production releases are tagged.
Everything else is done by Subversion revision number.

-- 
David Weintraub
qazwart@gmail.com

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

[Bob Archer <Bo...@amsi.com>]

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

No thank you. Since "tagging" is usually done at the file level and it can take forever. Yes you get an difference rev number in svn when you "tag" but um... frankly I ignore the rev numbers in svn. TSVN makes that very easy to do.

You'll get used to it quickly and probably prefer it too.

BOb

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

[Ryan Schmidt <su...@ryandesign.com>]

On Oct 13, 2010, at 14:05, LiuYan 刘研 wrote:
> 
> 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.

Do not let it confuse you. :) Perhaps it is easiest to think of the revision number as "the number of changes that have been made to the repository". That is all it is. It is a counter. You shouldn't assign any more significance to it than that.


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

Don't expect this to happen anytime soon. The request has come up many times over the years, but there are many different ideas that people have under the single term "labeling" (or "real tagging") and creating a complete correct description of the task, not to mention writing the code and testing and supporting it forever, is complicated. Subversion's existing tagging works fine for many cases so I imagine implementing "labeling" is not a high priority for developers.

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

[LiuYan 刘研 <lo...@21cn.com>]

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

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

[David Weintraub <qa...@gmail.com>]

On Wed, Oct 13, 2010 at 2:25 AM, LiuYan 刘研 <lo...@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@gmail.com

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

["Loritsch, Berin" <bl...@dtri.net>]

> 
> Hi all,
> 
> I'm new to subversion. I used CVSNT before.
> 
> 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).

There's no particular reason to do that.  Essentially subversion does all the record keeping for you so you can get back to any one revision.  It does so better than CVS did.

> But I'm afraid it's not a proper way, so:
> - Should file A and B be commited separately?
> - Should file A be commited more than once per day?
> - How to issue these commits when there's 1 single subversion user?
> - How to issue these commits in team working project?
> 
> Any advice will be appreciated.

Best advice is to have everyone commit when they are ready to commit.  Waiting too long increases the chance of a conflict.  SVN is designed to have multiple (even hundreds) clients all working with a central repository.  It takes a lot of the hard work about merging the changes from different users.  If everyone commits regularly, then you might get the occaisional message to update your local working copy before you commit--but that's about it.


Confidentiality Note: The information contained in this message, and any attachments, may contain proprietary and/or privileged material. It is intended solely for the person or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

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

[Nick Stolwijk <ni...@gmail.com>]

I try to commit the smallest amount of work worth committing. ie. Add
1 unit test, add code to make it all happen, commit. At least, that is
the ideal situation, most of the times it will amount to the work done
for one jira issue, or anything in between. But all code commited
together at least refers to one jira issue.

Hth,

Nick Stolwijk
~Java Developer~

IPROFS BV.
Claus Sluterweg 125
2012 WS Haarlem
http://www.iprofs.nl



On Wed, Oct 13, 2010 at 8:25 AM, LiuYan 刘研 <lo...@21cn.com> wrote:
> Hi all,
>
> I'm new to subversion. I used CVSNT before.
>
> 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?
> - Should file A be commited more than once per day?
> - How to issue these commits when there's 1 single subversion user?
> - How to issue these commits in team working project?
>
> Any advice will be appreciated.
>
>
>