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.
