Re: [zvtm-devel] how to build from SVN?

[Henrik L. <he...@ma...>]

Hi,

Regarding SVN
There is nothing magical about the folders named /tags, /trunk etc. they =
are
just conventions that many/most follow, so you are correct - all you =
need to
do is to create these folders and move the current folders into /trunk. =
At
the same time you may want to move the source folders into "/trunk/src" =
to
make the root under trunk look like the layout for the distribution (and
match the instructions in build.xml).

If you want to do more, it would be beneficial to break things up into
projects (like the optional gnb, and mdb). If you decide to do that I =
would
suggest a structure that looks like this:

/projectname1
   /trunk
       /projectname1
           /src
               /com
                   / .....
           build.xml
   /tags
      /projectname1-7.0.2a
          /projectname1
              (as under trunk)
      /projectname1-7.0.2b
          ...etc...etc
   /branches
/projectname2
   /trunk
   /tags
   /branches

This is the structure we are using, and it makes it very easy to get =
each
thing as a project, all names are compatible (i.e. you are working on
"projectname1" irrespective of if it is under a tag, the trunk or a =
branch.

If you don't want (sub)projects to have their own lifecycles, then =
/trunk,
/tags are at the top level with project names underneath, and then you =
tag
across all those (sub)projects.=20
I hope that was of value - how to set up the structure was something =
that
confused me at first when I started using SVN.

Statemachine.jar
Yes you are right - my mistake. I do have statemachine.jar.

Regarding reproducers etc. I will attach either SVG or dot files to =
issues
when appropriate.

If you are interested, here is some information about what I am working =
on:

My plan is to use the applet (or a modified version) to view graphs that =
I
generate on the fly. These graphs describe software components and their
dependencies on other components and some graphs will be quite large (my
first attempts produced PNGs that were > 64000 pixels high ! Needless to
say, the size of these PNGs are also quite large. Unfortunately the
uncompressed SVG output is just as large (or even larger) and hence my
interest in the applet viewer with support for svgz. I also need the =
viewer
since FF SVG does not render the dot SVG output correctly (fontsize is =
off),
and IE does not have native support for SVG so users would have to =
install a
SVG viewer (and Adobe has discontinued the SVG plugin in favour of Flash =
-
sigh). FF SVG croaks on very large SVG files. So ZGRViewer has many =
benefits
even without using the search, lenses etc.

I looked at the Yoix project as well as it renders the dot output =
directly
(and the dot output is much smaller than PNG and SVG), but I did not =
like
their approach with yet another language and environment on top of java. =
 (I
would really like to have a java implementation of dot as that would =
reduce
the size of the data that needs to be transferred to perhaps 50-100k
(compressed) as opposed to the several megabytes of PNG or SVG output
(uncompressed)). I have looked into dot algorithms, and also dot source =
and
that seems like a major undertaking to learn and recreate in java.

Anyway, the dependency graphs will be generated on the fly from our =
database
of dependencies, and we will graph the resolved configurations as well.
We are now just about to release our second alpha at
http://www.cloudsmith.com (alpha 1 is live there now and alpha 2 will be
released in a week or so). My plan is to add the graph viewing in the =
next
cycle - due in about a month. (The functionality to view graphs as PNGs =
and
raw DOT is available in the alpha 1, but there is no visible navigation =
to
it, in alpha 2 it will be possible to also obtain the SVG output. This =
is
what I am using when experimenting with the ZGRviewer applet.=20

I guess that was a very long way of saying that there will be plenty of
samples to try out for anyone :) all I need to do is to give you a URL.

I hope to get enough time to complete the things I want to do =
(compression),
and other small things for our next cycle. I may have time to fix other
ZGRViewer issues as well, and I will then submit patches. (Sometimes =
that is
quicker than writing a bug report :)).

Regards
- henrik

-----Original Message-----
From: Emmanuel Pietriga [mailto:emm...@in...]=20
Sent: torsdag 18 oktober 2007 18:55
To: he...@ma...; zvt...@li...
Subject: Re: [zvtm-devel] how to build from SVN?

On 18 oct. 07, at 18:06, Henrik Lindberg wrote:

> Regarding branching - agree that it is not fun to work with =20
> branches, but
> surely some mechanism is needed to maintain one version with =20
> bugfixes while
> continuing development on a new release? How did you plan to do that?
> Also, tagging is very useful, and without a top level folder where =20
> would you
> put the tagged versions? Even if not using branches a top level =20
> structure of
> /tags and /trunk would be of value.
> Another change that would make things easier would be to put the =20
> src in a
> /src directory (then the same setup is easy to use in both eclipse =20
> and in
> the ant build file).

I've been working mostly alone on this project until now, with a few =20
contributions from others that mostly occured at the time the code =20
was in CVS. And ZGRViewer is a "little" project. So I did not see the =20
need for branches/etc in there. I did not bother. But you are right. =20
It would be better to set things appropriately. The thing is, I am =20
not extremely used to SVN. I know how to perform the basic =20
operations. But that's it.

What would I need to do to make the SVN repository a "correct" one?
Simple make /trunk and /tags dirs and put what at the root right now =20
in /trunk?

Or is there more to it?


> Back to building.
> I had to build a new ZVTM as the newer viewer needed things from it.
> I built the ZVTM without the missing jars.

Except statemachine.jar I suppose.


> When running the built applet I see some problems and I wonder if =20
> these are
> known problems (primary reason for asking is to make sure the build =20
> I made
> is ok and not due to environment, use of Java 1.6 etc).

Of course there are known problems. And unknowns too!

> - when using a larger view area, the menu to the left is either always
> rendered (on top of the graph), and it can not be used, or it is =20
> not visible
> at all (and does not appear when moving mouse to left edge).

Weird. I thought I had fixed this one. But maybe I only fixed it in =20
the standalone version of ZGRViewer.


> - the two new visualizations (highlighting and animating nodes) are =20
> really
> cool, but not everything works ok - only parts of nodes are moved =20
> (I use
> rounded rectangles), arrow heads (I use stick arrows) are left =20
> behind where
> the nodes were.

I am aware of that. These are highly experimental. I started playing =20
with this idea, but there are still many things to do. I hope I'll be =20
able to dedicate some time to ZGRViewer within the coming weeks.


> - when running in the applet viewer (at least, have not tried it in a
> browser yet) the initial rendering of the graph does not occur =20
> until the
> mouse if brought over the graph area

Yes, I know. That's an issue. Might be related to bug #1809778. I =20
have to investigate.

http://sourceforge.net/tracker/index.php?=20
func=3Ddetail&aid=3D1809778&group_id=3D63244&atid=3D503313


> Other problems that are consistent in both the 0.7.2a and the =20
> version I
> built are:
> - rounded rectangles have thicker border on the rounded corners =20
> than the
> rest of the box
> - the non rounded part of rounded rectangle is not always rendered
> (typically the leftmost node in a horizontal dot layout).
> - the width of the line leading in to the tip of a stick arrow is much
> thinner than the line itself (up to the 'edge of the arrow' so to =20
> say).
> - If not all parameters for the applet are specified (highlight, =20
> backgrounds
> etc) then there are NPEs, and also warnings about XOR color that is =20
> null
> etc. There were logic to check input, but it does not seem to get =20
> it right.
> - Strange things happen when the applet gets a 404 for the svg URL, =20
> or is
> not fed a svgURL at all.
>
> Should I log errors/problems as I see them?

By all means. I wasn't aware of these problems. It would also be =20
great if you could provide means to reproduce the problem(s) for =20
rounded rectangles and line width vs. arrow (by way of small =20
example .dot files attached to the bug report).

Thanks for your help and feedback, it is most appreciated.
Emmanuel

--
Emmanuel Pietriga
INRIA Futurs - Projet In Situ    tel : +33 1 69 15 34 66
Bat 490, Universit=E9 Paris-Sud    fax : +33 1 69 15 65 86
91405 ORSAY Cedex FRANCE     http://www.lri.fr/~pietriga