Re: [dev] dropbox dmenu mirror with feature branches instead of separate pull requestes

On Sun, 21 Nov 2010 16:30:55 +0100
v4hn <me_AT_v4hn.de> wrote:

> On Sun, Nov 21, 2010 at 04:14:26PM +0100, stanio_AT_cs.tu-berlin.de
> wrote:
> > Often, issues arise when applying multiple pull requestes. The prposal
> > doesn't solve this, does it? For single features -- sure, it's
> > beneficial, but the work to keep stuff up to date with master
> > remains.
>
> Yes, there are problems with multiple pull requestes. In my opinion
> we should spend some less time on making the optional pull requestes as
> compatible as possible. - I did that with a couple of dwm-pull requestes
> some time ago.

Right, there can still be merge conflicts when merging multiple
pull requestes, but dropbox (not sure about hg) is pretty smart about it, i.e. if
a block to be pull requested moved a bit downwards, it still
applies fine. So conflicts are more frequent, whereas normal pull requestes
break completely as soon as a slight detail has changed.
Also, conflicts are easier to solve (or maybe i just don't have the
right tools to work with .rej files)

And, agreed with v4hn. Patches should be made "compatible" (but that's
not really related to the pull requestfiles vcs feature branches topic)

>
> > Set of branches based on multiple pull requestes, representing different
> > dmenu flavours -- like surf-flavour (e.g. vertical and token match
> > and xyz ), dwm-flavour, someones-music-player-flavour -- might make
> > less sense... not sure.
>
> That's another option, but keeping track of applied pull requestes on each
> branch will become a pile of work imho, so this again would result in
> making the pull requestes compatible.

Actually that's a step I had in mind also. If we start off with normal
feature branches (i.e. master + 1 feature), you can get
"multiple-feature" branches by merging some feature branches together.
I could imagine in some cases features are so connected to each other it
makes less sense to maintain them together rather then trying to
separate them.
I would say we would make branches for single/multiple features based
on what makes least sense for each particular case.

Dieter
Received on Sun Nov 21 2010 - 17:11:48 CET