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
