How to keep overview of branches and merges ( was /people/lazyboy/r-2_8_4-fai-cd_sarge_fixes - two bugfixes merged together)

[Henning Sprang]

On Wed, 2005-10-26 at 16:06 +0200, Holger Levsen wrote:
> Hi,
> 
> On Friday 21 October 2005 01:32, Henning Sprang wrote:
> > On the other hand, when multiple merges and branches exits in some time,
> > log messages can be difficult to oversee and are vulnerable to syntax
> > errors (simple example: you won't find commit message where somebody
> > writes "merging" when grepping for merge). Maybe a spreadsheet or a
> > database should be used sometime, until then the wiki might prove
> > useful.
> >
> > What do you think?
> 
> I would rather prefer a commit-log policy (again: keep it simple & short), so 
> that we all use "merge" instead of "merging"...

That was just one example of what I think can go wrong. I also have some
fear that with svn log output, you can lose overview very fast, when
having multiple branches and merges.

I have no imagination how it would be done for FAI when trying to
compare a list of available patches in some people branches against the
log of some release branch to see if all those patches are already in
how would that look like?

> 
> A spreadsheet or database would bei overkill, IMO.

I am using Openoffice spreadsheets for lots of stuff, so maybe that's
why I have trouble to see why it's such an overkill to use one one once
a week to document a merge. 
As Thomas is the one doing the merges in all branches from which
releases will be made, what does he think of this? Or do you have no
imagination yet because you didn't work with branches/merges at all
before, Thomas?

The one project I worked on with multiple branches and merges, used a
spreadsheet successfully, in addition to log messages. That's what I can
say from my experience.

Holger, how does the D.-I. project you are working on handle that? Do
other projects with multiple branches and merges use a
"commit-log-policy-only" solution successfully? 

Despite of all these open questions, I agree that we should start with
the simple solution first - we can start using another helper tool in
case we realize that commit logs are not enough.

What should a commit-log policy say? Would that be enough:

"When merging a branch into another one, the commit log should look
like:
merge - <BRANCH-OR-TAG-MERGED-IN-HERE>"

Or is there some other information needed?

Henning


.oO( Maybe going for Henning Glawe's proposal to use darcs would have
avoided those problems completely, but now we are here - BTW without
having based our decision for svn on the requirements list we made once,
because nobody had time/will to test the different tools available
against that list...)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.uni-koeln.de/pipermail/linux-fai-devel/attachments/20051027/23393895/attachment.bin