Moved READMEs to root directory so GitHub finds them

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)