Daniel Egger wrote: > >It is better all round if there are > >more frequent commits, each one making a distinct change. > > IMHO your given rule of a thumb is not completely correct because the > granule of a commit should not be the smallest possible change in a > single file but the smallest possible changeset covering all files > needed to be touched for a logical step.
This is what I meant above, although I can see how it might have been read differently. what I meant by "a distinct change" is precisely a changeset - something that has one paragraph in the ChangeLog, if you like. > Unfortunately with CVS that > requires a lot of discipline because it doesn't support the notion > of a changeset and creating and working with a branch is really > overkill in most cases. It kind of does - it's not changeset oriented in the way that BK or Arch are, but checking in several files at once is possible, and cvs2svn manages to make changesets out of commits that happen with the same comment, at the same time, by the same person for Subversion repositories. Anyway, the rule of thumb is "when you've finished a "thing", get it out of your local tree as quickly as possible (either by sending it to CVS or attaching it as a patch to a bug report). The "thing" could be a feature, a document, or a bug fix. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] _______________________________________________ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer