diff options
Diffstat (limited to 'muse2/README.svn-branch')
| -rw-r--r-- | muse2/README.svn-branch | 125 |
1 files changed, 125 insertions, 0 deletions
diff --git a/muse2/README.svn-branch b/muse2/README.svn-branch new file mode 100644 index 00000000..94e44ed8 --- /dev/null +++ b/muse2/README.svn-branch @@ -0,0 +1,125 @@ +Branches are handy for developing larger features (especially if you +temporarily break muse and then fix it again). You might want to ask +why you shouldn't simply develop in your local working copy, and then +commit a huge chunk. Well, this has multiple reasons: + o with branches, you'll have a history, because there are many small + commits. this makes bisecting for finding a bug possible. + o when you develop your feature publicly, others can check out half-done + versions, and already test the one half. they also could fix bugs. + o another advantage of keeping it public is: others can see whether you + may exclude some use case and inform you about that in time. otherwise + you'd spend lots of work in a design which was obsolete from the + beginning. + o and it shows that there's something going on :) + +also, branching makes "feature freezes" easier, for release planning. + +General note: ^/trunk means [url of the repo]/trunk. when you're inside +a working copy, svn understands the ^/trunk notation. +i assume you're inside some working copy + +whenever merging, make sure you're in the correct directory! + +CREATING A BRANCH + the following command creates a branch called yourbranch in the branches + directory, which is built upon the current (NOT the checked out!) trunk + revision: + + svn copy ^/trunk ^/branches/yourbranch + + svn copy does a "light copy", that is, as long as you don't change files, + they don't occupy any disk space. + +USING THE BRANCH + you might want to checkout every branch relevant to you into another local + copy. believe me, it makes life easier. alternatively, svn switch is your + friend. + just develop inside the working copy, then commit. + +MERGING WITH THE PARENT BRANCH (in my example: the trunk) + from time to time, you want to update your branch to represent the + current trunk plus your changes (and not an ancient trunk plus your + changes). to be safe, only merge with the parent branch, and only + merge in one direction (usually from trunk into your branch), unless + you know what you're doing. if you're reading and not skimming this, + you're probably NOT knowing. svn help and google are your friends. + + be in your branch'es working directory root (the dir which is containing + all the files/dirs also trunk (the parent) is containing as well. + + svn merge ^/trunk --accept postpone + + does the job for you. there might be conflicts, when both in your branch + and in trunk some file has been changes at a similar location. svn by + default asks you what to do then, which is annoying. --accept postpone + turns this off, and gives you a summary at the end of the merge. + + If There Were Conflicts: + if any file in "svn status"'s output has a C in front of it, there are + conflicts. open the file in your editor, and look for markers like + "<<<<<", "=====" and ">>>>>". these show what code is in the trunk + (between <<<< and ====), and what code is in your branch (between + ==== and >>>>) (or vice versa. svn tells you). + you have to make it work again and save the file. + + with "svn resolved FILENAME" or "svn resolved -R some/directory" you + mark the conflicts for FILENAME or all files below some/directory as + solved. + + Another word about conflicts: there may be conflicts, even if svn doesn't + note them. ALWAYS recompile the merged code and test it. + + if done, you can commit the merge normally using "svn commit" + +PUTTING YOUR WORK BACK INTO THE PARENT BRANCH (in my example: trunk) + do a final merge from your parent branch into your branch. compile and + test. + then there are several ways to proceed: + o use svn merge --reintegrate, which doesn't work with the old repo + version muse is using :( + o go into the trunk (or the parent branch'es directory), and issue + svn merge ^/branches/yourbranch --accept theirs-full + the problem with the merge is, that every previous merge from trunk + into your branch will be applied a second time, which doesn't work. + --accept theirs-full will basically use the files in your branch. + you might want to verify with diff: + diff -R /path/to/local/trunk /path/to/local/yourbranch + there should be no differences. + + commit that to trunk: svn commit + + then, "fake-merge" trunk into your branch again. otherwise, with the + next merge from trunk into your branch, we would have the duplicate + changes problem again. if you're _SURE_ that you aren't using the + branch any more, you can leave this step out. + + svn merge ^/trunk ^/branches/yourbranch --record-only + svn commit + + + this solution is a bit hackish :( but it works + + +NOTES FOR RELEASE BRANCHES + after creating the release branch, ALL commits which are fixing bugs + must go into the release branch. ALL commits which are adding features + must go into trunk or other branches. + the team should focus on fixing bugs in the release branch. + to get the fixes into the trunk, from time to time run: + + svn merge ^/branches/releasebranch ^/trunk + svn commit (in trunk's local copy) + + when releasing the release branch, merge it into the trunk a last time, + and then never touch the release branch again. + for the next release, create a new one. + +TAGGING + when there's any reason for tagging a revision, simply do + svn copy ^/whatever ^/tags/yourtagname + read the svn manual for details + +GETTING HELP: + svn help <command> (usage notes, short explanations) + google (everything) + the svn book (->google) (long explanations) |