-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Thank you all for the thorough explanations. I really enjoy the feedback here. Am 29.03.12 10:12, schrieb Martin Geisler:
It points out that the --reintegrate flag is critical for reintegrating changes from a branch back into trunk. They are talking about a scenario where you've continuously kept the branch up to date with changes from trunk and now want to merge back:
Correct.
trunk: a --- b --- c --- d --- e \ \ branch: r --- s --- t --- u
Because of the t revision, you cannot just replay the r:u changes on top of e: the u revision already contain some of the changes that are in e (the b and c changes).
My approach with svn without --reintegrate is: merge t into the trunk and use --record-only. This way the files stay unchanged, but the metadata (mergeinfo) will be updated to reflect that trunk now contains t. This is somewhat arkward, but in the end it enables a merge of the branch into the trunk. svn will then by itself patch r, s, and u into the trunk. So no three-way-merge here, but (maybe) a series of diffs that will get applied. The --reintegrate option will instead employ a three-way merge. I see how a merge of all of trunk into the branch just before merging the branch into trunk will help to reduce conflicts. So I consider - --reintegrate now. Maybe this is the point where git and hg have better handling of merges. What will happen in the above example with git or hg when merging the branch into trunk? Do you have to do a final merge from mainline into the branch? What will happen if you skip this step? I'm asking because I might want to cherry pick changes from either side and merge them into the other: some changes from trunk into the branch some other from the branch into trunk and at the end merge the whole branch into trunk. How is that supported?
That gives you two independent working copies.
By making a local clone you avoid downloading anything again. Furthermore, a local clone will make *hardlinks* between the files in the .hg/ directory. This means that both clones share the disk space: you only pay for creating a new working copy.
Is that supported on Windows as well?
With SVN you would have to make a new 'svn checkout' -- or I guess you can copy an existing checkout with 'cp' and then 'svn switch'? That way you avoid downloading the files that aren't affected by the switch.
Correct. And you will have to pay for duplicate files. SVN will keep a pristine copy of all files in its hidden directory. So every working copy will have its own set of pristine files, no hardlinks. With the pristine files you can view the current changes (svn diff) or revert files without contact to the repo.
Notice a fundamental difference in design here: Mercurial (and Git) have branches. Subversion don't:
http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.branchmerge.using.conce...
Instead, SVN has a cheap server-side copy mechanism and SVN allows you to checkout a single subdirectory at a time. SVN also allows you to merge changes made in a subdirectory into another subdirectory. These features let you "emulate" branches and tags, but they are not first-class citizens in the system.
Yes, I always thought the emulation was an advantage of svn because you don't have to learn another concept. Just copying directories to create branches allows to employ whatever organization of branches and tags you like: create /branches/releases to hold release branches if you like, create /users/myusername to supply everyone with their own sandbox, or create /proj1/trunk and /proj2/trunk in the same repo.
This in turn allows SVN to represent a richer history than Git and Mercurial. That is, I can do
svn cp ^/trunk/foo/bar ^/tags/bar-1.0 -m "branch"
to "tag" a random subdirectory. That operation doesn't make any sense in the other systems: there a tag references a commit and that's that. Depending on your viewpoint, you can say that Git and Mercurial models the history in a more clean way. You can also say that they lack a crucial feature :)
At least they disallow committing to tags by design. With svn handling of branches and tags is pure convention. Sometimes people don't adhere to the convention. Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: keyserver x-hkp://pool.sks-keyservers.net iEYEARECAAYFAk90qjEACgkQhAOUmAZhnmonSQCgiYUYNJmqDn6thIrVGOX0y8rl hcUAniNN1iPme/2TyOaHXGjzvQN9PORA =TLcK -----END PGP SIGNATURE-----