On 10/20/05, Giovanni Bajo <[EMAIL PROTECTED]> wrote: > Eric Botcazou <[EMAIL PROTECTED]> wrote: > > > I've never created/managed branches or tagged anything in the GCC > > tree. The important things to me are: > > > > - time to do a complete check-out on mainline/branch > > Check-out is 30% slower because of the time needed to write the duplicate > local > copy. On the other hand, there is a nice option "svn switch" which lets you > switch a working copy tree from mainling to any branch and viceversa just by > downloading the delta between the two, so much faster than checking out > everything from scratch. I can think of this workflow: > > - svn co path/to/mainline patch-sparc-frame-pointer (checkout pristine > tree > to work on a specific patch) > - Write/test patch on mainline. Review/commit it. Committed as r1234567 > (single > number identifies changes to 10 files, 1 rename, 2 deletions). > - From within .path-sparc-frame-pointer directory, svn switch > path/to/gcc40branch (switch to 4.0 branch) > - Backport patch: svn merge -r1234567 /path/to/mainline (automatically > rename, delete, apply modifies). > - Test/commit. > - svn switch path/to/gcc34/branch (switch to 3.4 branch) > - etc.
With SVK you could work with one working copy developing independent patches like start a local branch for patch1 $ svk copy //gcc //gcc-patch1 switch your working copy to that $ svk switch //gcc-patch1 develop, test, whatever. check in the changes to the local branch $ svk ci repeat for patches2..N when submitting one patch to mainline you can either go through patches or do merges like switch to HEAD $ svk switch //gcc merge from your branch $ svk smerge //gcc-patch1 push the changes to mainline as one new revision $ svk push -l or generate a patch out of the changes instead $ svk push -P patch-foobar.diff Please don't take this as exact way to do things, because this is from the docs only, and obviously I didn't try doing it. Richard.
