rails-devel — List for discussion of Rails development

Re: [Rails-devel] Bug fix: 1856 dit upgrade phases

[Frederick W. <fre...@go...>]

Bill:
Thanks for the details.
Unfortunately, I wasn't able to reproduce the exception, even when
disabling the grid table layout option.
But the details you provided were enough to identify the symptom
(getBorderInsets returns null on the field to be added). Now, the
GridPanel should be robust enough to handle that.

The problem is that this perhaps does not really help you as you
reported that the OR window didn't proceed to OR 1.1. I can't tell why
this is the case unless being able to reproduce the issue...

Would you mind checking what happens now on your local installation?

--Frederick

Re: [Rails-devel] Bug fix: 1856 dit upgrade phases

[Bill R. <ro...@gm...>]

On 2012-02-07, at 18:07 , Frederick Weld wrote:

> Bill:
> What symptom have you seen when running 1856 in master?
> - Is it that some class is not found? (the new libs have to added to
> the java project...)
> - Does the symptom only occur for the attached save games or also for new games?

I tried to create a (new) test game on the master branch.  The Private Auction and SR1 seemed to go well, but when I passed to end the stock round I could not seem to do anything for the operating rounds.  Upon trying again, there's a NullPointerException being thrown: see the stack trace below.  This is possibly some kind of Java version issue: I'm using the 1.6 that seems to have shipped with my operating system (Mac OS 10.6).  The same thing happens when I try to start a game of 1830 too, so I don't think it's 1856-specific.

If it's useful, the behaviour I see is: upon passing for the last player in the SR, all that seemed to happen was the cash totals per player were increased (as the privates had paid out).  At this point I was left looking at the main status screen with no indication of what to do next.  The 'autopass' button was still available, but pressing it seemed to have no effect.  I could locate the map window, but I wasn't able to operate the first company.  The home token was laid, but I could not select any hexes for track laying: clicking on the map seemed to have no effect.

The stack trace is:

Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
	at rails.ui.swing.GridPanel$FieldBorder.<init>(GridPanel.java:257)
	at rails.ui.swing.GridPanel.addField(GridPanel.java:125)
	at rails.ui.swing.ORPanel.initFields(ORPanel.java:606)
	at rails.ui.swing.ORPanel.recreate(ORPanel.java:266)
	at rails.ui.swing.ORWindow.activate(ORWindow.java:287)
	at rails.ui.swing.ORUIManager.initOR(ORUIManager.java:127)
	at rails.ui.swing.GameUIManager.updateUI(GameUIManager.java:433)
	at rails.ui.swing.GameUIManager.processAction(GameUIManager.java:300)
	at rails.ui.swing.StatusWindow.process(StatusWindow.java:683)
	at rails.ui.swing.StatusWindow.actionPerformed(StatusWindow.java:632)
	at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2028)
	at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2351)
	at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
	at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
	at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:236)
	at java.awt.Component.processMouseEvent(Component.java:6373)
	at javax.swing.JComponent.processMouseEvent(JComponent.java:3267)
	at java.awt.Component.processEvent(Component.java:6138)
	at java.awt.Container.processEvent(Container.java:2085)
	at java.awt.Component.dispatchEventImpl(Component.java:4735)
	at java.awt.Container.dispatchEventImpl(Container.java:2143)
	at java.awt.Component.dispatchEvent(Component.java:4565)
	at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4621)
	at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4282)
	at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4212)
	at java.awt.Container.dispatchEventImpl(Container.java:2129)
	at java.awt.Window.dispatchEventImpl(Window.java:2478)
	at java.awt.Component.dispatchEvent(Component.java:4565)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:679)
	at java.awt.EventQueue.access$000(EventQueue.java:85)
	at java.awt.EventQueue$1.run(EventQueue.java:638)
	at java.awt.EventQueue$1.run(EventQueue.java:636)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
	at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:98)
	at java.awt.EventQueue$2.run(EventQueue.java:652)
	at java.awt.EventQueue$2.run(EventQueue.java:650)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:649)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:296)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:211)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:201)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:196)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:188)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)

The output of java -version:
java version "1.6.0_29"
Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-10M3527)
Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode)

[Rails-devel] Release Rails 1.6.3 available

[Stefan F. <ste...@we...>]

A bug release for the 1.6.x branch.

Downloads are available at http://rails.sourceforge.net/ or by the
direct link http://sourceforge.net/projects/rails/files/Rails/1.6.3/

This release fixes one sole bug:
1856: Errors with late-game dit upgrade/downgrade - ID: 3485172

The bug effects all versions since (at least) Rails 1.5.1.

Thanks to Bill Rosgen for fixing the bug and Aliza Panitz for reporting.

Re: [Rails-devel] Bug fix: 1856 dit upgrade phases

[Frederick W. <fre...@go...>]

Bill:
What symptom have you seen when running 1856 in master?
- Is it that some class is not found? (the new libs have to added to
the java project...)
- Does the symptom only occur for the attached save games or also for new games?

-- Frederick

Re: [Rails-devel] Bug fix: 1856 dit upgrade phases

[Stefan F. <ste...@we...>]

Bill:
thanks for the patch. The git one works perfectly, so you can restrict 
yourself to that one in the future.

There will be another another bug-fix release later today.
Frederick could look into the issue of 1856 not running in master? Most 
likely that is due to customized UI classes?

Interestingly this is another case where there is no ex-post check for 
illegal actions in the game engine. Thus games can be loaded without an 
error even if the tile upgrade is considered illegal due to the changed
data files.

Stefan



On 02/07/2012 04:41 AM, Bill Rosgen wrote:
> Hello,
>
> I've attached a patch to fix the recently reported 1856 upgrade bug regarding which phases dits can be upgraded/downgraded in.  The problem is in the data files, where the phase names for these tile lays is incorrect (Phases 5,6 should be 6,D).
>
> I've also attached two savegames of a test game that show the problem: in the first, dits can be upgraded too early, as a 6 train has not yet been purchases, and in the second dits cannot be upgraded once a diesel has been bought.
>
> There are two patches, the first (0001-...) is in git format and the second (1856%3A...) is in Eclipse format.  Both patches are against the rails1.6.x branch, as with the recent UI work in master, I'm currently unable to get 1856 to work.  The patches should apply cleanly to master as well, but I'm not sure how hard it is to persuade git to do this without a cherry-pick.  If it is difficult to apply these patches, it may be easier to simply correct the data files by hand.
>
> Bill
>
>
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
>
>
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Bug fix: 1856 dit upgrade phases

[Bill R. <ro...@gm...>]

Hello,

I've attached a patch to fix the recently reported 1856 upgrade bug regarding which phases dits can be upgraded/downgraded in.  The problem is in the data files, where the phase names for these tile lays is incorrect (Phases 5,6 should be 6,D).  

I've also attached two savegames of a test game that show the problem: in the first, dits can be upgraded too early, as a 6 train has not yet been purchases, and in the second dits cannot be upgraded once a diesel has been bought.

There are two patches, the first (0001-...) is in git format and the second (1856%3A...) is in Eclipse format.  Both patches are against the rails1.6.x branch, as with the recent UI work in master, I'm currently unable to get 1856 to work.  The patches should apply cleanly to master as well, but I'm not sure how hard it is to persuade git to do this without a cherry-pick.  If it is difficult to apply these patches, it may be easier to simply correct the data files by hand.

Bill

Re: [Rails-devel] Swing Docking Framework for Rails

[Frederick W. <fre...@go...>]

Stefan:
> Maybe it is not messed up in your eyes ;-)
Apart from the map, the layout is ok / could be restored. BUT the map
is definitely missing on the screenshot. Even if it's just hidden
somewhere, you have proven that such situations could occur.
I'll think about how to deal with this finding.

-- Frederick

Re: [Rails-devel] Swing Docking Framework for Rails

[Stefan F. <ste...@we...>]

Frederick,
I simply played around for a minute and I came up with the following 
setup (see attachment). I do not even know where the map panel 
disappeared to.
Maybe it is not messed up in your eyes ;-)
Stefan

On 02/05/2012 02:49 PM, Frederick Weld wrote:
> Stefan:
>> After closing the Map/ORWindow via the GameWindow menu
>> and recreating it, only parts of the ORWindow get restored: However
>> which parts can be recovered changes each time I tried that.
>
> Thanks for this observation. This should now be fixed (retest
> successful at least for my reproduction path).
>
> Regarding the other points:
> I understand that much more would be needed if we wanted to really
> productize these new features (ie., defining them as standard).
> However, I have made the decision not to pursue this aim for the time
> being. Everyone who wants to make experiences with this (rather
> hidden) functionality is welcome to do so - he can return to the
> standard rails UI at any time.
>
> Some of the points in more detail:
>
> - Messed up layouts: It would be rather easy to add a "reset layout"
> button to the OR Panel's menu. But this would only help regarding the
> symptom. The root issue here is that you are able to create broken
> layouts. I have never been able to "achieve" that. I'm really
> wondering how you did this.
>
> - Predefined game-dependent layouts and config file merge: Very
> sensible but, in my opinion, much too early to think about that. One
> target design could be do put all panels (incl. status window etc.) in
> one frame. So this should wait until the target design is fixed.
>
> -- Frederick
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Swing Docking Framework for Rails

[Frederick W. <fre...@go...>]

Stefan:
> After closing the Map/ORWindow via the GameWindow menu
> and recreating it, only parts of the ORWindow get restored: However
> which parts can be recovered changes each time I tried that.

Thanks for this observation. This should now be fixed (retest
successful at least for my reproduction path).

Regarding the other points:
I understand that much more would be needed if we wanted to really
productize these new features (ie., defining them as standard).
However, I have made the decision not to pursue this aim for the time
being. Everyone who wants to make experiences with this (rather
hidden) functionality is welcome to do so - he can return to the
standard rails UI at any time.

Some of the points in more detail:

- Messed up layouts: It would be rather easy to add a "reset layout"
button to the OR Panel's menu. But this would only help regarding the
symptom. The root issue here is that you are able to create broken
layouts. I have never been able to "achieve" that. I'm really
wondering how you did this.

- Predefined game-dependent layouts and config file merge: Very
sensible but, in my opinion, much too early to think about that. One
target design could be do put all panels (incl. status window etc.) in
one frame. So this should wait until the target design is fixed.

-- Frederick

Re: [Rails-devel] Swing Docking Framework for Rails

[Stefan F. <ste...@we...>]

Frederick:
some quick replies and observations. Overall it seems to work without 
critical bugs, for me however it does not improve the handling so far.

* At least on my system (Linux KDE 4, Java OpenJDK/IcedTea 6) it is 
pretty easy to create a layout which is a complete messed up and it is 
nearly impossible to get back into something useful (via the UI and not 
by deleting the configuration file).

* More seriously: After closing the Map/ORWindow via the GameWindow menu 
and recreating it, only parts of the ORWindow get restored: However 
which parts can be recovered changes each time I tried that.

* It would be great if there were some pre-defined sensible layouts 
available to select from, especially if those are game dependent (for 
example taking into account how the map looks like and how many 
companies exist).

* Configuration files in general: There are now three types (my 
rails_config, Erik's rails_ini and Fredericks' DockableLayout/rails_ini) 
of configuration files saved using different mechanisms and file locations.
We should at least consider some consolidation here.

* Configuration and log-files: It would be nice if saving and opening of 
configuration files would be written to 18xx.log, which allows

* Size of the jar-files: In the long-run we should provide resource 
packages (e.g. for maps and libs), so that for updates only fewer files
should be required: The whole setup and installation mechanism is 
something we should have a look at.
However I believe that a size of 11MB is still very reasonable.

Stefan


On 02/04/2012 04:59 PM, Frederick Weld wrote:
> Erik/Stefan:
> based on your replies and my first experiences, I decided not to move
> substantially further with the adoption of the docking framework.
> There are several reasons for that:
> - I've already achieved my main goal of being able to detach panels
> from the OR window.
> - Demand beyond this is currently not clearly existing.
> - Any further adoption of the framework would be invasive and
> longer-term oriented (not being part of master).
>
> This decision means the following (already available in the repository):
>
> (1) docking framework included into master - but disabled by default
>         - option (within section "Window") for enabling dockable panels
> of the OR Window
>         - Anybody can evaluate the docking framework by activating
> option (no patch/branch need)
>
> (2) Only add a few key features in addition to the prototype
>         - the button panel can be detached
>              - e.g., I put it below the upgrade panel in my local layout
>         - the OR Window layout is persisted / restored on a per-game basis
>         - upgrade panel tiles are displayed in the same zoom step as in the map
>              - This wasn't possible before as the upgrade panel's width
> couldn't be adjusted
>
> (3) Refrain from refactoring OR window's panels
>         - supporting the configuration option renders such refactoring
> too cumbersome
>
> (4) Refrain from extending the scope of the docking framework to other
> windows/panels for the time being
>         - wait until there is the "pull" for more (based on others'
> experiences / feedback)
>
>> Erik:
>> [Docking Framework] It would release ORPanel again from its chains, but what other problems would it solve?
>
> Even for one monitor, I could perceive advantages of adopting the
> docking framework: Each round could have its own perspective which
> could be further configured by the user. Think of minimizing /
> reducing the size of the stock market / chart for ORs and the
> map/tracks during SR.
>
> -- Frederick
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Swing Docking Framework for Rails

[Frederick W. <fre...@go...>]

Erik:
As to the question whether it is possible to dock together two
externalized panels (eg., or panel and button panel), I have found the
definitive answer (and a how-to) in the forum (see
http://forum.byte-welt.de/showthread.php?p=13574): It is possible but
requires some adjustment of the framework's behavior.
That solution is now included in master (with some minor / but
necessary adjustments).

I think one could quickly learn the basics of the framework by
examining how ORWindow works now.

btw: It appears that the creator of docking frames (Benjamin Sigg -
Beni) provides excellent support for how-to questions regarding the
framework (in the forum).

-- Frederick

Re: [Rails-devel] Swing Docking Framework for Rails

[Erik V. <eri...@xs...>]

> > Certainly in such a case I would like to be able to detach the
> > existing ORPanel as a whole, i.e. including the buttons. Or move these
> > two panels into a different window.
> > Would such things be possible?
> 
> I don't know the docking framework enough to give a definitive answer to
> that. My guess is that this would be possible. (But the linked docs would
have
> to be consulted for how to achieve that.)
> 
> But how about docking the buttons together with the upgrade panel or at
> the right side of the OR window?

That's better, though not good enough for 1835.

Anyway, I'm getting the idea. It certainly looks promising.

Erik.

Re: [Rails-devel] Swing Docking Framework for Rails

[Frederick W. <fre...@go...>]

Erik:
> Certainly in such a case I would like to be able to detach the existing
> ORPanel as a whole, i.e. including the buttons. Or move these two panels
> into a different window.
> Would such things be possible?

I don't know the docking framework enough to give a definitive answer
to that. My guess is that this would be possible. (But the linked docs
would have to be consulted for how to achieve that.)

But how about docking the buttons together with the upgrade panel or
at the right side of the OR window? (Don't forget that I altered the
button panel's preferrence size such that the button may be listed
vertically or in a grid.)
My layout also looks like that (or panel dragged to the second monitor
while buttons docked just above the upgrade panel being part of OR
Window on the first monitor).

> The two extra jars take almost 3 MB.  That's pretty large.

I had also doubts on that at the beginning. But then again the 18GA
background map svgs also have a combined size of 3MB...

-- Frederick

Re: [Rails-devel] Swing Docking Framework for Rails

[Erik V. <eri...@xs...>]

Frederick,

It works fine, and I like it.  A few remarks: 

>        - the button panel can be detached
>             - e.g., I put it below the upgrade panel in my local layout

The extra space taken by the detachable panels is significant, and will
increase the need to actually do some detachment in many cases. 
This is particularly important for 1835 with its tall map.
Certainly in such a case I would like to be able to detach the existing
ORPanel as a whole, i.e. including the buttons. Or move these two panels
into a different window.  
Would such things be possible? 

> Each round could have its own perspective which could be
> further configured by the user.

Yes, enabling round-type dependent layouts would reduce my scepticism by a
lot.

The two extra jars take almost 3 MB.  That's pretty large.

Erik.

Re: [Rails-devel] Swing Docking Framework for Rails

[Frederick W. <fre...@go...>]

Erik/Stefan:
based on your replies and my first experiences, I decided not to move
substantially further with the adoption of the docking framework.
There are several reasons for that:
- I've already achieved my main goal of being able to detach panels
from the OR window.
- Demand beyond this is currently not clearly existing.
- Any further adoption of the framework would be invasive and
longer-term oriented (not being part of master).

This decision means the following (already available in the repository):

(1) docking framework included into master - but disabled by default
       - option (within section "Window") for enabling dockable panels
of the OR Window
       - Anybody can evaluate the docking framework by activating
option (no patch/branch need)

(2) Only add a few key features in addition to the prototype
       - the button panel can be detached
            - e.g., I put it below the upgrade panel in my local layout
       - the OR Window layout is persisted / restored on a per-game basis
       - upgrade panel tiles are displayed in the same zoom step as in the map
            - This wasn't possible before as the upgrade panel's width
couldn't be adjusted

(3) Refrain from refactoring OR window's panels
       - supporting the configuration option renders such refactoring
too cumbersome

(4) Refrain from extending the scope of the docking framework to other
windows/panels for the time being
       - wait until there is the "pull" for more (based on others'
experiences / feedback)

> Erik:
> [Docking Framework] It would release ORPanel again from its chains, but what other problems would it solve?

Even for one monitor, I could perceive advantages of adopting the
docking framework: Each round could have its own perspective which
could be further configured by the user. Think of minimizing /
reducing the size of the stock market / chart for ORs and the
map/tracks during SR.

-- Frederick

[Rails-devel] Nonmodal dialogs

[Erik V. <eri...@xs...>]

I have pushed another commit regarding the handling of nonmodal dialogs,
which has changed quite a lot.
Many dialogs now derive from the NonModalDialog abstract class.  All such
dialogs have a key (or name), which must be unique in the context of one
game.
That key is used to recognize the dialogs for postprocessing, rather than
the combination of dialog type and action type that was used so far in many
cases.
The keys should have a sensible name, so that recognition of which code
handles which dialog should now be much easier.

In particular a look at GameUIManager_18EU and GameUIManager should reveal
how it all works, and how different dialogs can be chained easily.

This mail is also intended to be a response to Martin's request to get a
hand to deal with his 1880 dialogs.  Hopefully a look at the current code
will give him an easier start.

Erik

Re: [Rails-devel] Swing Docking Framework for Rails

[Erik V. <eri...@xs...>]

> the errors occur as Eclipse does not refresh all folders after the
> patch: It seems that it does not refresh the library folder, so it does
not find
> the new libraries. However this is not too surprising as the lib folder is
> excluded from being a source folder for Rails.
> So you have to refresh that path manually.

It was not Eclipse but (command-line) git (Git Bash) that gave these errors.

> It is too easy to get this gimp-like feeling as a user that you have never
know
> where each menu item might be hidden.
> So I agree with Erik that this is most likely to be a major rework and
cannot be
> done easily in a evolutionary fashion.
> 
> So my suggestion is to synchronize that work with my Rails 2.0 development
> to avoid rewriting it for 1.x first and than having to adapt it to 2.0
again.

A note aside: I suspect that saved docking layouts should be game-dependent,
as window sizes (in particular the map) differ widely.

Erik.

Re: [Rails-devel] Swing Docking Framework for Rails

[Stefan F. <ste...@we...>]

Erik:
the errors occur as Eclipse does not refresh all folders after the 
patch: It seems that it does not refresh the library folder, so it does 
not find the new libraries. However this is not too surprising as the 
lib folder is excluded from being a source folder for Rails.
So you have to refresh that path manually.
Stefan


Frederick:

I did some quick testing:
It is great to be able to drag around panels as you wish .
However as it is the case with docking frameworks is that it allows 
users to easily mess-up the layout of panels, if there is not 
intelligent algorithm triggering resizes or adding scrollbars to the panels.

It is too easy to get this gimp-like feeling as a user that you have 
never know where each menu item might be hidden.
So I agree with Erik that this is most likely to be a major rework and 
cannot be done easily in a evolutionary fashion.

So my suggestion is to synchronize that work with my Rails 2.0 
development to avoid rewriting it for 1.x first and than having to adapt 
it to 2.0 again.

Stefan


On 02/02/2012 07:51 PM, Erik Vos wrote:
> Frederick,
>
> When I tried to load the first patch (with 'git am'), I got errors like:
> .classpath does not match index
> build.xml does not match index
> Not sure what to do about these errors.
>
> The second patch loaded fine.
>
> I think it's fine to experiment with such ideas, but I'm a bit sceptical
> about the result.  Yes, it would release ORPanel again from its chains, but
> what other problems would it solve?
> My main issue is, that our screens are (or at least mine is) too small to
> have all frames open at a convenient size, and at the same time not overlap
> each other. I don't immediately see how docking could fix that. But I may be
> wrong.
>
> In any case, I would prefer docking to remain optional.  And out of the way
> (i.e. in a separate branch) until it's proven to work and do a better job
> (whatever that means).
>
> Erik.
>
>> -----Original Message-----
>> From: Frederick Weld [mailto:fre...@go...]
>> Sent: Thursday, February 02, 2012 4:16 PM
>> To: Development list for Rails: an 18xx game
>> Subject: Re: [Rails-devel] Swing Docking Framework for Rails
>>
>> Stefan/Brett/Erik:
>>> I do not know if everyone has to commit to one framework before you
>> could start.
>>
>> Understood. But then at least Erik and me should have the same opinion on
>> this issue, as we are currently the only ones actively working on the UI
> layer.
>> On top of that, the docking framework adoption would be a refactoring of
>> the current UI (not an additional UI) - as changing frameworks would be
>> rather invasive.
>>
>> ==>  I'll wait for Erik's opinion / assessment before moving on.
>>
>>> When considering any libraries or frameworks for use, please only
> consider
>> those with GPL-compatible licensing.
>>
>> The lib's licence is LGPLv2.1 which is listed as GPL-compatible. So that
> would
>> be ok.
>>
>> -- Frederick
>>
>>
> ----------------------------------------------------------------------------
> --
>> Keep Your Developer Skills Current with LearnDevNow!
>> The most comprehensive online learning library for Microsoft developers is
>> just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro
>> Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-d2d
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Swing Docking Framework for Rails

[Erik V. <eri...@xs...>]

Frederick,

When I tried to load the first patch (with 'git am'), I got errors like:
.classpath does not match index
build.xml does not match index
Not sure what to do about these errors.

The second patch loaded fine.

I think it's fine to experiment with such ideas, but I'm a bit sceptical
about the result.  Yes, it would release ORPanel again from its chains, but
what other problems would it solve?
My main issue is, that our screens are (or at least mine is) too small to
have all frames open at a convenient size, and at the same time not overlap
each other. I don't immediately see how docking could fix that. But I may be
wrong.  

In any case, I would prefer docking to remain optional.  And out of the way
(i.e. in a separate branch) until it's proven to work and do a better job
(whatever that means).

Erik.

> -----Original Message-----
> From: Frederick Weld [mailto:fre...@go...]
> Sent: Thursday, February 02, 2012 4:16 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Swing Docking Framework for Rails
> 
> Stefan/Brett/Erik:
> > I do not know if everyone has to commit to one framework before you
> could start.
> 
> Understood. But then at least Erik and me should have the same opinion on
> this issue, as we are currently the only ones actively working on the UI
layer.
> On top of that, the docking framework adoption would be a refactoring of
> the current UI (not an additional UI) - as changing frameworks would be
> rather invasive.
> 
> ==> I'll wait for Erik's opinion / assessment before moving on.
> 
> > When considering any libraries or frameworks for use, please only
consider
> those with GPL-compatible licensing.
> 
> The lib's licence is LGPLv2.1 which is listed as GPL-compatible. So that
would
> be ok.
> 
> -- Frederick
> 
>
----------------------------------------------------------------------------
--
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers is
> just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro
> Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Swing Docking Framework for Rails

[Frederick W. <fre...@go...>]

Stefan/Brett/Erik:
> I do not know if everyone has to commit to one framework before you could start.

Understood. But then at least Erik and me should have the same opinion
on this issue, as we are currently the only ones actively working on
the UI layer.
On top of that, the docking framework adoption would be a refactoring
of the current UI (not an additional UI) - as changing frameworks
would be rather invasive.

==> I'll wait for Erik's opinion / assessment before moving on.

> When considering any libraries or frameworks for use, please only consider those with GPL-compatible licensing.

The lib's licence is LGPLv2.1 which is listed as GPL-compatible. So
that would be ok.

-- Frederick

Re: [Rails-devel] Swing Docking Framework for Rails

[brett l. <bre...@gm...>]

On Thu, Feb 2, 2012 at 8:35 AM, Stefan Frey <ste...@we...> wrote:
> Frederick:
>
> thanks for sharing your prototype.
>
> A general remark first:
> Agreement on the tools is good, however I do not know if everyone has to
> commit to one framework before you could start.
> Three reasons for that: First Rails could support several UIs and second
> the one who codes is the one who has to live with the choice.
> And third not everyone has the time to do a full evaluation, so most
> cannot commit themselves at this time.
> If you come up with something that looks nice both in practice and in
> code people will trust that your choice was the right one.
>

+1. Agreed.

>
> On the choice of libraries:
> A docking framework was on my radar at the time I started coding on
> Rails. I actually did have a look at some of the frameworks (but not
> actually trying to code against them) and DockingFrames was my favorite
> at that time too (and it is still under development, which is good given
> that Swing is not a rising star anymore). Alternatives at that time I
> really considered have been Infonode (dual licensed with GPL) or Jide
> (provides free licences to open source projects on request).
>

A quick note about licensing. This is an incredibly thorny issue. I
don't want to jump too far down this rabbit hole, but I'd like to
provide at least some basic guidance.

When considering any libraries or frameworks for use, please only
consider those with GPL-compatible licensing. (See:
http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses )

Our main code base is licensed under the GPL v2 or newer, and so any
libraries or frameworks we rely on must be able to play nicely with
our own code. :-)

> I also had a look at alternative LayoutManagers and my preference there
> was to test at least DesignGridLayout
> (http://designgridlayout.java.net/index.html), which seems both easy to
> use and provides a lot of features.
>
> UI development in the longer run:
> That is my major concern at the moment: One of the design goals of
> Rails2.0 state and model refactoring is the optimization of UI update
> messages: The amount of round-trip messages between the game engine and
> the UI should be minimal to allow running the game over low-bandwidth
> and latent connections. This would strongly broaden the possibilities of
> UI creation to have the UI for example running inside a browser or on a
> mobile gadget.
> Still as this is a long-run development it does not conflict with your
> short to medium-term of refactoring the Swing UI, but I want to share
> my thoughts on that.
>
> A target for me that comes before rewriting the UI, but still after the
> core Rails2.0 refactoring is multi-player support via the internet.
> My current intention is to employ the XMPP-Protocol, which should in
> principle allow us to rely on existing XMPP-servers which provide the
> required functionality. This might have some impact on the UI, but I do
> not expect that to be to serious, as in a first approach every player
> will have its own game engine running on its local PC which are
> synchronized via messages (similar to how VASSAL works, but replacing
> the central VASSAL server by a multi-puropose XMPP server, which if I
> remember correctly is something VASSAL intends to do in the future too).
>
> No time to have a look at the patch so far, so nothing on that.
>
> Stefan
>

---Brett.

>
>
> On 02/02/2012 01:56 PM, Frederick Weld wrote:
>> I've done some internet research for finding the "best" LGPL Swing
>> docking framework, which appears to be DockingFrames. Based on that
>> framework, I developed a very small prototype that puts that OR Window
>> on the docking framework.
>>
>> Instead of pushing to prototype to the dev branch, I attached it as
>> patches so that you can have a look at this technology.
>>
>> In any case, I think we need to have a strong buy-in by everyone
>> before being able to move to this framework.
>>
>> -- Frederick
>>
>> ===============
>> Details: DockingFrames
>> ===============
>>
>> Links:
>> - Homepage: http://dock.javaforge.com/
>> - Javadoc: http://dock.javaforge.com/dockingFrames_v1.1.0/doc/index.html
>> - Examples: http://dock.javaforge.com/help.html
>> - Forum: http://forum.byte-welt.de/forumdisplay.php?f=69&langid=2
>>
>> Key advantages (at the first glance)
>> - LGPL
>> - Allows for both
>>     - convenient access to docking functionality ("common" jar")
>>         ->  easy to start with (see prototype)
>>     - deep configurability ("core" jar)
>>         ->  easy to adapt to future more sophisticated requirements
>> - Rich feature set
>>
>> ===============
>> Details: Prototype
>> ===============
>>
>> Implementation:
>> - added just about 20 lines to ORWindow
>> - had to suppress triggering ORWindow revalidation as the docking
>> framework takes care of that
>>
>> First findings:
>> - dockables can be detached from their master frame
>>     ->  finally, the OR panel can be put somewhere else
>> - Stefan will like the docking tooltips - others probably not... ^_^
>>     - but should be no issue to find out how to set them to English
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Keep Your Developer Skills Current with LearnDevNow!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-d2d
>>
>>
>>
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Swing Docking Framework for Rails

[Stefan F. <ste...@we...>]

Frederick:

thanks for sharing your prototype.

A general remark first:
Agreement on the tools is good, however I do not know if everyone has to 
commit to one framework before you could start.
Three reasons for that: First Rails could support several UIs and second
the one who codes is the one who has to live with the choice.
And third not everyone has the time to do a full evaluation, so most 
cannot commit themselves at this time.
If you come up with something that looks nice both in practice and in 
code people will trust that your choice was the right one.


On the choice of libraries:
A docking framework was on my radar at the time I started coding on 
Rails. I actually did have a look at some of the frameworks (but not 
actually trying to code against them) and DockingFrames was my favorite
at that time too (and it is still under development, which is good given 
that Swing is not a rising star anymore). Alternatives at that time I 
really considered have been Infonode (dual licensed with GPL) or Jide 
(provides free licences to open source projects on request).

I also had a look at alternative LayoutManagers and my preference there 
was to test at least DesignGridLayout 
(http://designgridlayout.java.net/index.html), which seems both easy to 
use and provides a lot of features.

UI development in the longer run:
That is my major concern at the moment: One of the design goals of 
Rails2.0 state and model refactoring is the optimization of UI update 
messages: The amount of round-trip messages between the game engine and 
the UI should be minimal to allow running the game over low-bandwidth 
and latent connections. This would strongly broaden the possibilities of 
UI creation to have the UI for example running inside a browser or on a 
mobile gadget.
Still as this is a long-run development it does not conflict with your 
short to medium-term of refactoring the Swing UI, but I want to share
my thoughts on that.

A target for me that comes before rewriting the UI, but still after the 
core Rails2.0 refactoring is multi-player support via the internet.
My current intention is to employ the XMPP-Protocol, which should in 
principle allow us to rely on existing XMPP-servers which provide the 
required functionality. This might have some impact on the UI, but I do 
not expect that to be to serious, as in a first approach every player 
will have its own game engine running on its local PC which are 
synchronized via messages (similar to how VASSAL works, but replacing 
the central VASSAL server by a multi-puropose XMPP server, which if I 
remember correctly is something VASSAL intends to do in the future too).

No time to have a look at the patch so far, so nothing on that.

Stefan



On 02/02/2012 01:56 PM, Frederick Weld wrote:
> I've done some internet research for finding the "best" LGPL Swing
> docking framework, which appears to be DockingFrames. Based on that
> framework, I developed a very small prototype that puts that OR Window
> on the docking framework.
>
> Instead of pushing to prototype to the dev branch, I attached it as
> patches so that you can have a look at this technology.
>
> In any case, I think we need to have a strong buy-in by everyone
> before being able to move to this framework.
>
> -- Frederick
>
> ===============
> Details: DockingFrames
> ===============
>
> Links:
> - Homepage: http://dock.javaforge.com/
> - Javadoc: http://dock.javaforge.com/dockingFrames_v1.1.0/doc/index.html
> - Examples: http://dock.javaforge.com/help.html
> - Forum: http://forum.byte-welt.de/forumdisplay.php?f=69&langid=2
>
> Key advantages (at the first glance)
> - LGPL
> - Allows for both
>     - convenient access to docking functionality ("common" jar")
>         ->  easy to start with (see prototype)
>     - deep configurability ("core" jar)
>         ->  easy to adapt to future more sophisticated requirements
> - Rich feature set
>
> ===============
> Details: Prototype
> ===============
>
> Implementation:
> - added just about 20 lines to ORWindow
> - had to suppress triggering ORWindow revalidation as the docking
> framework takes care of that
>
> First findings:
> - dockables can be detached from their master frame
>     ->  finally, the OR panel can be put somewhere else
> - Stefan will like the docking tooltips - others probably not... ^_^
>     - but should be no issue to find out how to set them to English
>
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
>
>
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Swing Docking Framework for Rails

[Frederick W. <fre...@go...>]

I've done some internet research for finding the "best" LGPL Swing
docking framework, which appears to be DockingFrames. Based on that
framework, I developed a very small prototype that puts that OR Window
on the docking framework.

Instead of pushing to prototype to the dev branch, I attached it as
patches so that you can have a look at this technology.

In any case, I think we need to have a strong buy-in by everyone
before being able to move to this framework.

-- Frederick

===============
Details: DockingFrames
===============

Links:
- Homepage: http://dock.javaforge.com/
- Javadoc: http://dock.javaforge.com/dockingFrames_v1.1.0/doc/index.html
- Examples: http://dock.javaforge.com/help.html
- Forum: http://forum.byte-welt.de/forumdisplay.php?f=69&langid=2

Key advantages (at the first glance)
- LGPL
- Allows for both
   - convenient access to docking functionality ("common" jar")
       -> easy to start with (see prototype)
   - deep configurability ("core" jar)
       -> easy to adapt to future more sophisticated requirements
- Rich feature set

===============
Details: Prototype
===============

Implementation:
- added just about 20 lines to ORWindow
- had to suppress triggering ORWindow revalidation as the docking
framework takes care of that

First findings:
- dockables can be detached from their master frame
   -> finally, the OR panel can be put somewhere else
- Stefan will like the docking tooltips - others probably not... ^_^
   - but should be no issue to find out how to set them to English

Re: [Rails-devel] git branching maintenance release (was; 1830 RSM Fix included)

[brett l. <bre...@gm...>]

Awesome. I'm actually happy to be wrong on this. It's nice to see that
git is smart enough to not bring in unrelated changes.

Thanks for testing this. :-)

---Brett.



On Wed, Feb 1, 2012 at 1:47 PM, Stefan Frey <ste...@we...> wrote:
> Brett:
> I did test it and actually it works as I wished it work: It only takes
> the commits from feature after it branched from master and applies those
> on top of the maintenance branch. And it does not add anything from
> those commits from the time between where maintenance branched until
> feature branched.
>
> So the workflow for a hotfix is:
>
> git checkout -b feature
> ... code & commit ...
> git rebase master
> git checkout master
> git merge feature
>
> followed by
>
> git rebase --onto maintenance master feature
> git checkout maintenance
> git merge feature
>
> How is this possible?
> You are right that git only cares about node relationships, however with
> three arguments to rebase git can figure out what do:
>
> Looking at the history of master and maintenance git knows that
> the latter branched after D.
> Looking at the history of master and feature git knows that the
> latter branched after N.
>
> Combining that information git knows that the commits between D and N
> are actually not "new" part of feature.
>
> Stefan
>
>
> On 02/01/2012 06:55 PM, brett lentz wrote:
>> The problem is all of the commits in between (The C->N commits). This
>> is, admittedly, where my experience with git runs a little thin, so
>> please feel free to test this out on your local repositories. (Hooray
>> distributed SCM!)
>>
>> I *believe* what will happen if you rebase onto the maintenance
>> branch, then merge after first having rebased onto master, will look
>> something like this...
>>
>>
>>                                          ->J->K->L
>>                                         /               \
>>    A->B->C->D->H->I->M->N---------------->O
>>                \
>>                 ->E->F-G--------------------------------------->P
>>                              \                                       /.
>>                               ->D->H->I->M->N->J->K->L
>>
>>
>> Where P is another merge commit, just like O.
>>
>> Feel free to test this out and prove me right/wrong. :-) However, I'm
>> pretty sure this is what will happen because git doesn't know or care
>> about the context of the commits, but only cares about their
>> parent/child relationships. So, once you've rebased your local branch
>> onto the latest master, the parent commit of J *is* N, and so when you
>> rebase onto the maintenance branch, it sees that the shared point C
>> begins to diverge at D/E and, therefore from D to N is considered "new
>> work" relative to the maintenance branch, exactly the same as the J to
>> L commits that you really want on the maintenance branch.
>>
>> I think the way around this is to create *two* private feature
>> branches, rebase one onto master and rebase the other onto the
>> maintenance branch, and either merge or cherry-pick your commits
>> between your two private feature branches in whatever way makes sense
>> in your work flow.
>>
>> ---Brett.
>>
>>
>>
>> On Wed, Feb 1, 2012 at 12:37 PM, Stefan Frey<ste...@we...>  wrote:
>>> Brett:
>>> thanks for this excellent explanation.
>>> So I got lucky that I have used a valid workflow from the beginning. And
>>> indeed I applied the -x flag.
>>>
>>> However I am still wondering if it would be possible to "rebase back to
>>> the past"?
>>>
>>>
>>>                                       ->J->K->L
>>>                                      /               \
>>>   A->B->C->D->H-I->M->N---------------->O
>>>               \
>>>                ->E->F-G
>>>
>>> If I understand rebase correctly the command (assume that J to L is
>>> branch feature, A to O to master and G to maintenance)
>>>
>>> rebase --onto maintenance master feature
>>>
>>> should end up with same result?
>>>
>>> A->B->C->D->H-I->M->N---------------->O
>>>               \
>>>                ->E->F-G->P(J)->Q(K)->R(L)
>>>
>>> Stefan
>>>
>>>
>>>
>>> On 02/01/2012 05:37 PM, brett lentz wrote:
>>>> So...  there's a couple ways to do this, depending on what end-result we want.
>>>>
>>>> As Stefan mentions, cherry-picking is one of the better options for
>>>> this. Changes should be merged into master, and then cherry-picked
>>>> into the feature branch. Ideally, all cherry-picks should use the "-x"
>>>> flag, which appends a line to your commit message saying where it was
>>>> cherry-picked from. This is important because, otherwise, cherry-picks
>>>> are commits that are wholly disconnected from their parent commit, so
>>>> the chain of history is not well-preserved with cherry-picks.
>>>>
>>>> Remember, git cares about *history* far more than it does about any
>>>> particular change. It tracks changes by parent-child relationships, so
>>>> we need to be aware of when we're breaking that relationship.
>>>>
>>>> This is also what makes rebasing against two different branches
>>>> somewhat problematic. Here's an example. (Hopefully my bad ascii art
>>>> displays correctly on your side)
>>>>
>>>> Imagine commits in master look something like this:
>>>>
>>>> A ->    B ->    C ->    D
>>>>
>>>> Then, we create a release, and create a maintenance branch for the release:
>>>>
>>>> A->B->C->D->H-I
>>>>              \
>>>>               ->E->F-G
>>>>
>>>> Now, let's say more work is done, including some work I've done on a
>>>> feature in my own local branch:
>>>>
>>>>                         ->J->K->L
>>>>                        /
>>>> A->B->C->D->H-I->M->N
>>>>              \
>>>>               ->E->F-G
>>>>
>>>>
>>>> So...  now let's say I rebase my local branch against master. This
>>>> rewinds my local branch to the common point in both branch's history
>>>> (H), then replays the commits that were in master so my local branch
>>>> "catches up", like so:
>>>>
>>>>                                      ->J->K->L
>>>>                                     /
>>>> A->B->C->D->H-I->M->N
>>>>              \
>>>>               ->E->F-G
>>>>
>>>> Git has reordered the history on my local branch. This is important
>>>> because most traditional SCMs don't allow you to rewrite history. Git
>>>> does, but it expects you to understand that this is what you're doing.
>>>>
>>>> This allows me to now merge my changes into master cleanly at the most
>>>> current point in the history:
>>>>
>>>>                                      ->J->K->L
>>>>                                     /               \
>>>> A->B->C->D->H-I->M->N---------------->O
>>>>              \
>>>>               ->E->F-G
>>>>
>>>> Note, O is a merge commit that has no content of it's own, but marks
>>>> the point in the history where there is multiple parents.
>>>>
>>>> So, now the question is... how do I get my changes into the maintenance branch?
>>>>
>>>> If I rebase my local tree a second time, git will again rewind to the
>>>> common ancestor (C) and... it will see all of the new changes from
>>>> master as if they were changes I had made in my local branch, because
>>>> they are not common to the maintenance branch. This means that a bunch
>>>> of stuff from master will be brought into the maintenance branch.
>>>>
>>>> Maybe that's what we want, and maybe it isn't.
>>>>
>>>> However, the alternative is to cherry-pick *only* my changes out of
>>>> either master or my local branch, divorce them from the history, and
>>>> append them into the maintenance branch, like so:
>>>>
>>>>
>>>>                                      ->J->K->L
>>>>                                     /               \
>>>> A->B->C->D->H-I->M->N---------------->O
>>>>              \
>>>>               ->E->F-G->P(J)->Q(K)->R(L)
>>>>
>>>>
>>>> Hopefully that helps. :-)
>>>>
>>>> ---Brett.
>>>>
>>>>
>>>>
>>>> On Wed, Feb 1, 2012 at 9:56 AM, Stefan Frey<ste...@we...>    wrote:
>>>>> Frederick:
>>>>> My solution for this currently is to git cherry-pick the
>>>>> bug-fix commit into the 1.6.x branch.
>>>>>
>>>>> Usually bug fixes do not effect lots of file, and if there
>>>>> is a conflict it is usually easy to resolve.
>>>>>
>>>>> But the main reason for this solution is that usually I receive the
>>>>> bug-fixes as already merged into master.
>>>>>
>>>>> Should it not be possible to first rebase on master, then revert that
>>>>> rebase and then rebase on 1.6.x.?
>>>>>
>>>>> However I am curious if Brett has a better recommendation.
>>>>>
>>>>> Stefan
>>>>>
>>>>>
>>>>>
>>>>> On 02/01/2012 03:48 PM, Frederick Weld wrote:
>>>>>> Brett:
>>>>>> So what would be the git command sequence when wanting to create a fix
>>>>>> in a separate branch which is to be merged back to both 1.6.x and
>>>>>> master (You could copy-paste aforementioned order as a template)?
>>>>>>
>>>>>> If rebasing is done before merging into 1.6.x and master, the hotfix
>>>>>> commit will be altered (and not be the same as used in 1.6.x).
>>>>>> Probably no big issue as 1.6.x and master will never be merged again.
>>>>>>
>>>>>> --Frederick
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Keep Your Developer Skills Current with LearnDevNow!
>>>>>> The most comprehensive online learning library for Microsoft developers
>>>>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>>>>>> Metro Style Apps, more. Free future releases when you subscribe now!
>>>>>> http://p.sf.net/sfu/learndevnow-d2d
>>>>>> _______________________________________________
>>>>>> Rails-devel mailing list
>>>>>> Rai...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Keep Your Developer Skills Current with LearnDevNow!
>>>>> The most comprehensive online learning library for Microsoft developers
>>>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>>>>> Metro Style Apps, more. Free future releases when you subscribe now!
>>>>> http://p.sf.net/sfu/learndevnow-d2d
>>>>> _______________________________________________
>>>>> Rails-devel mailing list
>>>>> Rai...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Keep Your Developer Skills Current with LearnDevNow!
>>>> The most comprehensive online learning library for Microsoft developers
>>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>>>> Metro Style Apps, more. Free future releases when you subscribe now!
>>>> http://p.sf.net/sfu/learndevnow-d2d
>>>> _______________________________________________
>>>> Rails-devel mailing list
>>>> Rai...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Keep Your Developer Skills Current with LearnDevNow!
>>> The most comprehensive online learning library for Microsoft developers
>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>>> Metro Style Apps, more. Free future releases when you subscribe now!
>>> http://p.sf.net/sfu/learndevnow-d2d
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>> ------------------------------------------------------------------------------
>> Keep Your Developer Skills Current with LearnDevNow!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-d2d
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] git branching maintenance release (was; 1830 RSM Fix included)

[Stefan F. <ste...@we...>]

Brett:
I did test it and actually it works as I wished it work: It only takes 
the commits from feature after it branched from master and applies those
on top of the maintenance branch. And it does not add anything from 
those commits from the time between where maintenance branched until 
feature branched.

So the workflow for a hotfix is:

git checkout -b feature
... code & commit ...
git rebase master
git checkout master
git merge feature

followed by

git rebase --onto maintenance master feature
git checkout maintenance
git merge feature

How is this possible?
You are right that git only cares about node relationships, however with 
three arguments to rebase git can figure out what do:

Looking at the history of master and maintenance git knows that
the latter branched after D.
Looking at the history of master and feature git knows that the
latter branched after N.

Combining that information git knows that the commits between D and N
are actually not "new" part of feature.

Stefan


On 02/01/2012 06:55 PM, brett lentz wrote:
> The problem is all of the commits in between (The C->N commits). This
> is, admittedly, where my experience with git runs a little thin, so
> please feel free to test this out on your local repositories. (Hooray
> distributed SCM!)
>
> I *believe* what will happen if you rebase onto the maintenance
> branch, then merge after first having rebased onto master, will look
> something like this...
>
>
>                                          ->J->K->L
>                                         /               \
>    A->B->C->D->H->I->M->N---------------->O
>                \
>                 ->E->F-G--------------------------------------->P
>                              \                                       /.
>                               ->D->H->I->M->N->J->K->L
>
>
> Where P is another merge commit, just like O.
>
> Feel free to test this out and prove me right/wrong. :-) However, I'm
> pretty sure this is what will happen because git doesn't know or care
> about the context of the commits, but only cares about their
> parent/child relationships. So, once you've rebased your local branch
> onto the latest master, the parent commit of J *is* N, and so when you
> rebase onto the maintenance branch, it sees that the shared point C
> begins to diverge at D/E and, therefore from D to N is considered "new
> work" relative to the maintenance branch, exactly the same as the J to
> L commits that you really want on the maintenance branch.
>
> I think the way around this is to create *two* private feature
> branches, rebase one onto master and rebase the other onto the
> maintenance branch, and either merge or cherry-pick your commits
> between your two private feature branches in whatever way makes sense
> in your work flow.
>
> ---Brett.
>
>
>
> On Wed, Feb 1, 2012 at 12:37 PM, Stefan Frey<ste...@we...>  wrote:
>> Brett:
>> thanks for this excellent explanation.
>> So I got lucky that I have used a valid workflow from the beginning. And
>> indeed I applied the -x flag.
>>
>> However I am still wondering if it would be possible to "rebase back to
>> the past"?
>>
>>
>>                                       ->J->K->L
>>                                      /               \
>>   A->B->C->D->H-I->M->N---------------->O
>>               \
>>                ->E->F-G
>>
>> If I understand rebase correctly the command (assume that J to L is
>> branch feature, A to O to master and G to maintenance)
>>
>> rebase --onto maintenance master feature
>>
>> should end up with same result?
>>
>> A->B->C->D->H-I->M->N---------------->O
>>               \
>>                ->E->F-G->P(J)->Q(K)->R(L)
>>
>> Stefan
>>
>>
>>
>> On 02/01/2012 05:37 PM, brett lentz wrote:
>>> So...  there's a couple ways to do this, depending on what end-result we want.
>>>
>>> As Stefan mentions, cherry-picking is one of the better options for
>>> this. Changes should be merged into master, and then cherry-picked
>>> into the feature branch. Ideally, all cherry-picks should use the "-x"
>>> flag, which appends a line to your commit message saying where it was
>>> cherry-picked from. This is important because, otherwise, cherry-picks
>>> are commits that are wholly disconnected from their parent commit, so
>>> the chain of history is not well-preserved with cherry-picks.
>>>
>>> Remember, git cares about *history* far more than it does about any
>>> particular change. It tracks changes by parent-child relationships, so
>>> we need to be aware of when we're breaking that relationship.
>>>
>>> This is also what makes rebasing against two different branches
>>> somewhat problematic. Here's an example. (Hopefully my bad ascii art
>>> displays correctly on your side)
>>>
>>> Imagine commits in master look something like this:
>>>
>>> A ->    B ->    C ->    D
>>>
>>> Then, we create a release, and create a maintenance branch for the release:
>>>
>>> A->B->C->D->H-I
>>>              \
>>>               ->E->F-G
>>>
>>> Now, let's say more work is done, including some work I've done on a
>>> feature in my own local branch:
>>>
>>>                         ->J->K->L
>>>                        /
>>> A->B->C->D->H-I->M->N
>>>              \
>>>               ->E->F-G
>>>
>>>
>>> So...  now let's say I rebase my local branch against master. This
>>> rewinds my local branch to the common point in both branch's history
>>> (H), then replays the commits that were in master so my local branch
>>> "catches up", like so:
>>>
>>>                                      ->J->K->L
>>>                                     /
>>> A->B->C->D->H-I->M->N
>>>              \
>>>               ->E->F-G
>>>
>>> Git has reordered the history on my local branch. This is important
>>> because most traditional SCMs don't allow you to rewrite history. Git
>>> does, but it expects you to understand that this is what you're doing.
>>>
>>> This allows me to now merge my changes into master cleanly at the most
>>> current point in the history:
>>>
>>>                                      ->J->K->L
>>>                                     /               \
>>> A->B->C->D->H-I->M->N---------------->O
>>>              \
>>>               ->E->F-G
>>>
>>> Note, O is a merge commit that has no content of it's own, but marks
>>> the point in the history where there is multiple parents.
>>>
>>> So, now the question is... how do I get my changes into the maintenance branch?
>>>
>>> If I rebase my local tree a second time, git will again rewind to the
>>> common ancestor (C) and... it will see all of the new changes from
>>> master as if they were changes I had made in my local branch, because
>>> they are not common to the maintenance branch. This means that a bunch
>>> of stuff from master will be brought into the maintenance branch.
>>>
>>> Maybe that's what we want, and maybe it isn't.
>>>
>>> However, the alternative is to cherry-pick *only* my changes out of
>>> either master or my local branch, divorce them from the history, and
>>> append them into the maintenance branch, like so:
>>>
>>>
>>>                                      ->J->K->L
>>>                                     /               \
>>> A->B->C->D->H-I->M->N---------------->O
>>>              \
>>>               ->E->F-G->P(J)->Q(K)->R(L)
>>>
>>>
>>> Hopefully that helps. :-)
>>>
>>> ---Brett.
>>>
>>>
>>>
>>> On Wed, Feb 1, 2012 at 9:56 AM, Stefan Frey<ste...@we...>    wrote:
>>>> Frederick:
>>>> My solution for this currently is to git cherry-pick the
>>>> bug-fix commit into the 1.6.x branch.
>>>>
>>>> Usually bug fixes do not effect lots of file, and if there
>>>> is a conflict it is usually easy to resolve.
>>>>
>>>> But the main reason for this solution is that usually I receive the
>>>> bug-fixes as already merged into master.
>>>>
>>>> Should it not be possible to first rebase on master, then revert that
>>>> rebase and then rebase on 1.6.x.?
>>>>
>>>> However I am curious if Brett has a better recommendation.
>>>>
>>>> Stefan
>>>>
>>>>
>>>>
>>>> On 02/01/2012 03:48 PM, Frederick Weld wrote:
>>>>> Brett:
>>>>> So what would be the git command sequence when wanting to create a fix
>>>>> in a separate branch which is to be merged back to both 1.6.x and
>>>>> master (You could copy-paste aforementioned order as a template)?
>>>>>
>>>>> If rebasing is done before merging into 1.6.x and master, the hotfix
>>>>> commit will be altered (and not be the same as used in 1.6.x).
>>>>> Probably no big issue as 1.6.x and master will never be merged again.
>>>>>
>>>>> --Frederick
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Keep Your Developer Skills Current with LearnDevNow!
>>>>> The most comprehensive online learning library for Microsoft developers
>>>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>>>>> Metro Style Apps, more. Free future releases when you subscribe now!
>>>>> http://p.sf.net/sfu/learndevnow-d2d
>>>>> _______________________________________________
>>>>> Rails-devel mailing list
>>>>> Rai...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Keep Your Developer Skills Current with LearnDevNow!
>>>> The most comprehensive online learning library for Microsoft developers
>>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>>>> Metro Style Apps, more. Free future releases when you subscribe now!
>>>> http://p.sf.net/sfu/learndevnow-d2d
>>>> _______________________________________________
>>>> Rails-devel mailing list
>>>> Rai...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Keep Your Developer Skills Current with LearnDevNow!
>>> The most comprehensive online learning library for Microsoft developers
>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>>> Metro Style Apps, more. Free future releases when you subscribe now!
>>> http://p.sf.net/sfu/learndevnow-d2d
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Keep Your Developer Skills Current with LearnDevNow!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-d2d
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel