[Fwd: Re: thoughts about branches]

Henning Sprang henning_sprang at gmx.de
Wed Oct 19 15:25:37 CEST 2005


sorry, forgot to send this to the list, also...


-------- Forwarded Message --------
From: Henning Sprang <henning_sprang at gmx.de>
To: Thomas Lange <lange at informatik.uni-koeln.de>
Subject: Re: thoughts about branches
Date: Tue, 18 Oct 2005 18:46:52 +0200
On Tue, 2005-10-18 at 16:19 +0200, Thomas Lange wrote:
> >>>>> On Tue, 18 Oct 2005 14:35:01 +0200, Henning Sprang <henning_sprang at gmx.de> said:
> 
>     > When somebody fixes a specific bug in his people branch successfully, he
>     > should document that in the BTS. So, its easy to find, and, through svn
>     > easy to apply and test for others.
> Yep. This is very important. So it's easy to find the patch in the svn.
> Could someone please add this to the svn policy/howto in the faiwiki.

I'll take care of that later, together with the recommendation on where
somebody should put the code for the bugfix, as soon as we have a
consens for that.

What did you think about the other advices I wrote in my first mail in
this thread (run linda, lintian, ...)?

> 
>     > But do you want to do only _one_ single bugfix branch, and fix _all_
>     > bugs in there? How will you then extract single patches?
> I thought about this:
> /bugs/<bugnummer>/
> 
> So in addition to a people branch we would create a bugs branch und
> which everybody can create a branch for evcery bug. But maybe the
> solution above (add link to the svn tree into the BTS) will be enough.
> 
>     > Or do you propose to have something like /branches/bug/<BUGNUMBER> for
>     > each bug? That I think is an idea we could consider. Still, it could
> Yep.
> 
>     > How would we regulate who is allowed to commit in
>     > which /branches/bugfix/<BUGNUMBER> branch? As For now, "normal"
>     > developers are not allowed to commit anywhere but /people/, but we need
>     > to commit in svn to share our bugfix proposals.
> Commit access is regulated with our policy. Do only commit in your tree.

So I can only put bugfixes in my people branches directory, and then
it's best to do it in /people/<MYNAME>/bugfixes/<BUGNUMBER>.

> 
>     > With that considered, having all in /people is still easier. 
> I'm still open for this solution, and maybe the bugs branch is not
> needed if we document where the patch can be found.

O.K.

> 
>     > Example:
>     > When Florent and me will work on fai-multi-distribution, where will we
>     > do that?
>     > in /people/lazyboy/fai-multi-distribution or
>     > in /people/florent/fai-multi-distribution ? or both, and the results
>     > will be merged in /braches/fai-multi-distribution? 
> That's up to you. You can both commit to each others tree if you
> like. But you should choose a name that indicates which version is the
> main/best/newest version of your work.

I will think about how it's best doing that...

>     > BTW: the svn book says: "branches are cheap, so use them liberally" ...
> I think I need some more expirences which branches and merging to see
> if it really makes sense to use branches for small patches. So where's
> the first patch I can merge?

Erm, you probably want to read the Branching/merging chapter of the
svnbook again and play around with branching in a testing repository,
and especially merging, and multiple time merging, before doing that in
a production environment.

I read the svnbook chapters about branching an merging in the meantime,
I am not already completely sure what's the best way to handle long-term
branches and multiple merging to them from trunk, so the development
doesn't get too far away from trunk, I also need some thinking and
testing for that.

For the simple bugfix branches, they are not such a problem...

For the real life test, I'll get the 320024 fix tested and can commit it
then tonite. You can merge it in the 2.8.5 release branch, which you
still need to create, and then put it together with the patch for
334333, then we finally have a working fai-cd.

Henning







More information about the linux-fai-devel mailing list