Re: [boost] [git] Mercurial? easy merging in svn, how about git/hg?

Subject: Re: [boost] [git] Mercurial? easy merging in svn, how about git/hg?
From: Frank Birbacher (bloodymir.crap_at_[hidden])
Date: 2012-03-29 14:30:09

-----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.concepts
>
>  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-----