Re: juggling patches...

["Max Bowsher" <maxb at ukf dot net>]

Robert Collins wrote:
> As we have multiple reviews of patches going on, overlapping patches
> will naturally conflict...
>
> So, I'm repeating an offer made here a long while back: cvs branches can
> be used for developing patches.
>
> i.e. maxb_UserSettings would be a branch of setup for Max to work on
> user settings.

Thanks for the offer - but I won't be doing this:

I'm currently restricted to dialup internet until I return to university -
CVS operations are just too slow.

Plus, I already get the functionality of cvs merging, by keeping one working
directory per project.

And lastly, I'm always somewhat cautious about touching a remote repository.
For example: I had to get Chris to run some cvs admin commands for me
recently.

> Scripts for branch creation and removal are in the cygwin CVS tree.
>
> If you don't have CVS access write access, don't have a local CVS copy
> of setup, or want to use the sources.redhat.com tree for branched
> development, get my ok, and then fill out the form referenced here a
> week or so ago.
>
> How it helps?
>
> Using Igor's work as an example, each patch gets it's own branch.
> i.e : igor_ScriptLogging and igor_ScriptOrdering
>
> Then as each patch develops, it just gets checked in, along with extra
> files etc.
>
> As HEAD changes, the patch can be syncronised via a cvsmerge HEAD
> command. (See the scripts :}).
>
> When the patch is ready, anyone with HEAD write permission (as opposed
> to HEAD write *access*)

What's the difference?

> :} can obtain the patch via a simple cvs rdiff,
> or use the cvsmkpatch script.
>
> Taken together this means:
> patches won't conflict with each other.

Well, they still will, but the conflicts will be more rigidly isolated until
final merge.

> patches have history.

At some point, excess history becomes clutter, though.

> work-in-progress can be easily reviewed.

Is it really any easier?

Max.