[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Strictness

From: Robert Collins
Subject: Re: Strictness
Date: Mon, 13 Aug 2007 08:54:52 +1000

On Sun, 2007-08-12 at 23:40 +0100, Noah Slater wrote:
> > I disagree. In a centralised VCS sure, you can scale to 100's of commits
> > a day - but in a distributed VCS - e.g. bzr, git, hg, monotone ... you
> > tend to get 100's of commits on branches, and a much smaller number of
> > branch merges occuring - branch merges being the point at which code
> > review is done, regression tests run etc. And its entirely appropriate
> > to create a human meaningful summary of the aggregate work done on that
> > branch.
> Actually - this argument doesn't support your conclusion.
> In Subversion (as an example) if you were merging branch A to the
> trunk after 10 commits you would have one revision entry for the merge
> - not the aggregate of all 10. So in this instance the commit message
> would be the description of the merge and the ChangeLog would (like I
> previously stated) make sense copying this exactly...

Well, in other VCS's the merged revisions are preserved. So 'log' shows
you the merge revision, and the log for the other revisions. Theres a
certain amount of repetition if you pull everything across, so what I've
seen a number of projects do is to do a fairly trivial commit message
and have the ChangeLog updated by the merge.

> ... which once again begs the question - why bother?

I think this boils down to 'do you think there is any disconnect between
commits to the VCS and telling humans whats happened from release to

I think there is.

GPG key available at: <>.

Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]