summaryrefslogtreecommitdiff
path: root/muse2/README.svn-branch
diff options
context:
space:
mode:
authorFlorian Jung <flo@windfisch.org>2011-12-21 17:39:57 +0000
committerFlorian Jung <flo@windfisch.org>2011-12-21 17:39:57 +0000
commit1057d7190242cdf9248671b316a398db805f5f56 (patch)
treeab50268a7db2f80cfb45a7ad6578fe735ab84ce5 /muse2/README.svn-branch
parent9977c7114089b8708d310268833b83343caa0fd1 (diff)
parentc36a5508aa42e596b005425208054af9a60734b4 (diff)
merged with trunk (that is, pulled the fixes from release_2_0)
only quickly tested, seems okay on the first glance
Diffstat (limited to 'muse2/README.svn-branch')
-rw-r--r--muse2/README.svn-branch125
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)