Doing merges properly [was: Re: [Sablevm-developer] Some improvements to sablevm-classpath]

[Grzegorz B. P. <ga...@de...>]

W li=B6cie z wto, 15-06-2004, godz. 08:52, Roman Kennke pisze:=20
> > Attached is a patch, that should get these changes into the tree.
>=20
> The mandatory forget-the-attachment thing. I will never learn this.

Acutally, it's not mandatory.  Actually, instead of a patch, normally
you send the following kind of information:

svn merge -r xxxx:yyyy $SVN/developers/.../sandbox/sablevm...

where:
- yyyy is the revision (version) you want to get merged
- xxxx is the revision (version) from which you started your changes.

yyyy is usually simply the latest revision (altough you should indicate
the number and not give a moving target like "HEAD") you see after doing
'svn up' in your working copy

xxxx might be a bit confusing at the first sight, but this is indeed
quite simple.  Usually this is the revision, at which you created your
branch.  If you had your changes from your private branch already
merged into "staging", then this is the revision of the "yyyy" value
of this previous merge.

You should *never* do merges by applying diff between your branch and
*current* version of "staging".  Why? Consider the following example,
that simulates what would happen if we did that.=20

$ printf "a\nb\nc\nd\n" >> ./staging   # initialize staging
$ cat ./staging=20
a
b
c
d
$ cp ./staging ./sandbox   # create development branch in sandbox
# meanwhile do some improvements in staging (below)
$ sed s/a/X/ ./staging >>./staging.new ; mv ./staging.new ./staging
$ cat ./staging=20
X
b
c
d
$ echo E >>./sandbox    # do some improvements in sandbox
$ cat ./sandbox=20
a
b
c
d
E
$ diff -u ./staging ./sandbox >>./for_merge_WRONG  # prepare diff
$ patch ./staging ./for_merge_WRONG=20
patching file ./staging
$ cat ./staging=20
a
b
c
d
E

Which is ***WRONG*** - because this way we lost all the improvements
done in staging!!!  The proper way of getting the diff for merge is
to get diff between the original version copied into sandbox and
the final version in sandbox - and apply the diff to staging.
There's nothing Subversion-specific in this.  This is how diff/patch
works.

I hope it's clearer now? :-)

Cheers,

				Grzegorz B. Prokopski

PS: Cc:ing Chris, as he had exactly the same problem lately.

PPS: The proper content of staging after a good merge would be:
$ cat staging
X
b
c
d
e

--=20
Grzegorz B. Prokopski      <ga...@de...>
Debian GNU/Linux           http://www.debian.org
SableVM - LGPL'ed Java VM  http://www.sablevm.org
Why SableVM ?!?            http://devel.sablevm.org/wiki/Features