Final tasks for making jME 2.0 stable

archive development-discussion-jme2
21
basixs said:

Alot of the features you mentioned are actually just user contributions and not part of jME itself,


That is exactly what I mean, some of them should be part of jME core... ask permission to integrate them to the core, clean them up, write some tests, announce them in jME2 with much fanfarre. And of course also do this for the new core changes!
22

Maybe a bit offtopic, sorry, but will gl context sharing be part of the 2.0 release ?

23
Vardamir said:

At work, we don't put branches under the branches directory, because merging its easier. The layout would be:
trunk
2.0.x
.
.


But, rightly or wrongly, some tools assume the standard layout to function correctly (the Polarion Subversion plug-in for Eclipse used to be this way for example).

Although I don't really have a strong preference either way.
24
ianp said:

But, rightly or wrongly, some tools assume the standard layout to function correctly (the Polarion Subversion plug-in for Eclipse used to be this way for example).


Ahh, now that's one of the reasons i prefer subclipse over subversive
25
Vardamir said:

Ahh, now that's one of the reasons i prefer subclipse over subversive


Well, me too these days :D but I used to use Subversive a couple of years ago.
26
Vardamir said:

Stable versions go to branches/<version> and development is in trunk. That's common.
But i have a little hint/idea/advice ;)

At work, we don't put branches under the branches directory, because merging its easier. The layout would be:

trunk
2.0.x
.
.

This way you dont always have to enter "branches/<version>", but only have tor replace "trunk"  with "<version" or "<version>" with "trunk" when you merge some bugfix from stable up to trunk.

While i'm typing this, i have the impression, that i have already typed something like this elsewhere....


I'm for deviating from convention if there is an overriding benefit, but the effort to discuss this topic has already exceeded the net microseconds from the difference... never mind the limitations it adds.  Your work layout only accommodates version branches, but not prototyping or tentative work branches (meaning that the root dir becomes a cluttered mess without "trunk" being clearly differentiated).  In these cases, you can use good, descriptive names if the parent directory indicates that they are branches.  WRT the time savings, if manually entering paths, the difference is between

http://jmonkeyengine.googlecode.com/svn/branches/collada-refactor

and

http://jmonkeyengine.googlecode.com/svn/collada-refactor

Big deal.  The difference is a single click or less if using a visual navigator.
27

Sure, but if you have a lot of versions to maintain, with fixes that have to go up all that versions, its a real annoying task in TortoiseSVN (which we use at work) to merge those fixes up the version tree.



You are right, it's not a big deal, but what are the major advantage of a branches sub directory? After a while, this directory gets a mess too. You still can put prototypes and personal branches in the branches directory.



It's a simple question of organisation. Look at linux, once there was a clean directory structure, but now, its a mess.

28
Vardamir said:

Sure, but if you have a lot of versions to maintain, with fixes that have to go up all that versions, its a real annoying task in TortoiseSVN (which we use at work) to merge those fixes up the version tree.

You are right, it's not a big deal, but what are the major advantage of a branches sub directory? After a while, this directory gets a mess too. You still can put prototypes and personal branches in the branches directory.

It's a simple question of organisation. Look at linux, once there was a clean directory structure, but now, its a mess.


The whole purpose of the /trunk, /tags, /branches directory is that is cleanly differentiates and categorizes the directory trees rooted in them.  If you look at the root of Linux, you will see that it is still much more clean than if we followed your advice and planted everthing in the root.


beyla$ ls /
bin   dev  home  lib64  lost+found  mnt  proc  sbin  sys  usr  wingamedisk
boot  etc  lib   local  media       opt  root  srv   tmp  var  xp
beyla$



I'm with the majority of Subversion developers who think it is useful to differentiate non-trunk branches from the trunk branch.  But no point arguing over it.  I think it organizes the branches better and you don't.  What I think we agree on is that if we switched to your plan it would have negligible benefits and the JME project's repository would have an unconventional layout.
29

This layout is subversion "best practice", but i dont like it. But it's common sense, so we should go for it