sablevm-developer

[Sablevm-developer] Some improvements to sablevm-classpath

[Roman K. <ro...@on...>]

Hi list,

I've made some improvements to sablevm-classpath, that I wish can
someday be merged into staging.

* Added some checks to autogen.sh, for compatibility with FreeBSD.
* Added javax/swing/Spring.java and javax/swing/SpringLayout.java.
(should work correctly).
* Added constructor ImageIcon(java.awt.Image img) to
javax/swing/ImageIcon.java.
* java/net/URLStreamHandler now correctly parses filenames as URLs.

Attached is a patch, that should get these changes into the tree.

I also made a SVN-tag:
svn+ssh://svn.sablevm.org/developers/roman/tags/sablevm-classpath-15-06-2004

could you check+comment-on this?

Thank you, 
/Roman

Re: [Sablevm-developer] Some improvements to sablevm-classpath

[Roman K. <ro...@on...>]

> Attached is a patch, that should get these changes into the tree.

The mandatory forget-the-attachment thing. I will never learn this.

/Roman

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

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

[Etienne G. <gag...@uq...>]

Actually...

Grzegorz B. Prokopski wrote:
> 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...


I really prefer to get a simple tag URL, such as:

$SVN/developers/name/tags/date-tagname

Why?

Because I prefer to rely on the output of:
   svn log $SVN/developers/name/tags/date-tagname
to find about xxx, and there's no way to get yyyy wrong when you use 
HEAD, given that tags cannot be modified.  :-)

[clarification: tags can be created, deleted, and re-created, but not 
modified.]

Etienne

-- 
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

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