diff options
Diffstat (limited to 'muse2/README.svn-branch')
| -rw-r--r-- | muse2/README.svn-branch | 125 |
1 files changed, 0 insertions, 125 deletions
diff --git a/muse2/README.svn-branch b/muse2/README.svn-branch deleted file mode 100644 index 94e44ed8..00000000 --- a/muse2/README.svn-branch +++ /dev/null @@ -1,125 +0,0 @@ -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) |