rails-devel — List for discussion of Rails development

Re: [Rails-devel] Emergency train purchases

[Chris S. <chr...@gm...>]

I'm pretty sure there are games where a company is not required to buy a
train from the pool, but may instead use emergency money raising to buy a
more expensive train from the bank.  I'm at work and don't have access to my
games and rules, so I can't verify this right now.

--
Chris

Please consider the environment before printing this e-mail.


On Mon, Jul 25, 2011 at 4:42 AM, Erik Vos <eri...@xs...> wrote:

> I'm working to get the emergency train buying rules right.  Currently, all
> Rails games follow the 1830 rules, and several people have already
> complained about that.
>
> In this stage I do not aim at getting all the details in all games
> completely implemented.
> However, I think I have identified the main options and sorted out how
> these
> apply to most of the games that we have been working on so far.
>
> The below only applies to companies that must own a train.  That excludes
> 1825.
>
> 1. If a company has no train, it can buy any train on offer from Bank, Pool
> or other companies (at any price) that is has enough cash for.
> It is always obliged to buy a used (Pool) train that it can pay for, if it
> cannot afford a new (IPO) train.
> It is never obliged to buy a train from another company.
> Only if no affordable train can be found this way, the President can and
> indeed must add cash, and the below rules apply.
>
> 2. Must buy the *cheapest* train from Bank or Pool:
> 1830/Kaas, 1856/70, 18AL/GA/TN, 1826: Yes.
> 1835, 18EU/VA/Scan: No.
>
> 3. May buy a train from another company (always up to list price):
> 1830/Kaas, 1835, 18EU/VA/Scan, 1826: Yes.
> 1856/70, 18AL/GA/TN: No.
>
> 4. President may add extra cash above the agreed price (up to list price)
> if
> buying from another company:
> 1830/Kaas: Yes.  It seems that this even applies if the company has
> sufficient cash for the agreed price.
> 18EU: Yes, but only if the company had exactly zero cash.
> All others: No or N/A.
>
> Any corrections to the above summary?
>
> Any more fine details for these games, and extensions to other games, are
> welcome, but will probably be end up in the for-later-study archive.
> I had a brief look into 1880, but it's not clear to me what the verdicts
> are
> for this game.
>
> Erik.
>
>
>
> ------------------------------------------------------------------------------
> Storage Efficiency Calculator
> This modeling tool is based on patent-pending intellectual property that
> has been used successfully in hundreds of IBM storage optimization engage-
> ments, worldwide.  Store less, Store more with what you own, Move data to
> the right place. Try It Now!
> http://www.accelacomm.com/jaw/sfnl/114/51427378/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Emergency train purchases

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

I think I must make the following amendment (at least 18EU spells this out):

4. President may add extra cash above the agreed price (up to list price) if
buying from another company:
===> ... but not more than the cash on hand. In this case no share selling
allowed. <===

> -----Original Message-----
> From: Erik Vos [mailto:eri...@xs...]
> Sent: Monday, July 25, 2011 1:42 PM
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] Emergency train purchases
> 
> I'm working to get the emergency train buying rules right.  Currently, all
Rails
> games follow the 1830 rules, and several people have already complained
> about that.
> 
> In this stage I do not aim at getting all the details in all games
completely
> implemented.
> However, I think I have identified the main options and sorted out how
these
> apply to most of the games that we have been working on so far.
> 
> The below only applies to companies that must own a train.  That excludes
> 1825.
> 
> 1. If a company has no train, it can buy any train on offer from Bank,
Pool or
> other companies (at any price) that is has enough cash for.
> It is always obliged to buy a used (Pool) train that it can pay for, if it
cannot
> afford a new (IPO) train.
> It is never obliged to buy a train from another company.
> Only if no affordable train can be found this way, the President can and
> indeed must add cash, and the below rules apply.
> 
> 2. Must buy the *cheapest* train from Bank or Pool:
> 1830/Kaas, 1856/70, 18AL/GA/TN, 1826: Yes.
> 1835, 18EU/VA/Scan: No.
> 
> 3. May buy a train from another company (always up to list price):
> 1830/Kaas, 1835, 18EU/VA/Scan, 1826: Yes.
> 1856/70, 18AL/GA/TN: No.
> 
> 4. President may add extra cash above the agreed price (up to list price)
if
> buying from another company:
> 1830/Kaas: Yes.  It seems that this even applies if the company has
sufficient
> cash for the agreed price.
> 18EU: Yes, but only if the company had exactly zero cash.
> All others: No or N/A.
> 
> Any corrections to the above summary?
> 
> Any more fine details for these games, and extensions to other games, are
> welcome, but will probably be end up in the for-later-study archive.
> I had a brief look into 1880, but it's not clear to me what the verdicts
are for
> this game.
> 
> Erik.
> 
> 
>
----------------------------------------------------------------------------
--
> Storage Efficiency Calculator
> This modeling tool is based on patent-pending intellectual property that
has
> been used successfully in hundreds of IBM storage optimization engage-
> ments, worldwide.  Store less, Store more with what you own, Move data to
> the right place. Try It Now!
> http://www.accelacomm.com/jaw/sfnl/114/51427378/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Emergency train purchases

[John A. T. <ja...@ja...>]

On Mon, Jul 25, 2011 at 7:42 AM, Erik Vos <eri...@xs...> wrote:

> In this stage I do not aim at getting all the details in all games
> completely implemented.
> However, I think I have identified the main options and sorted out how
> these
> apply to most of the games that we have been working on so far.
>

In games with double-sided trains, usually you are not constrained to buying
the cheapest available -- ie, you can decide to buy it as the more expensive
train type, putting in more out of hand.  Some of these games say you can't
sell stock to buy the more expensive train, but can only use president cash.

-- 
John A. Tamplin

Re: [Rails-devel] Emergency train purchases

[Phil D. <de...@gm...>]

We played 1880 yesterday and our belief was the following:

If the company has at least $1 and no train then it can buy a train
from a company owned by the same director.
If the company has $0, or the director does not wish to buy a train
from a 'friend' then it must buy the cheapest train from the bank
(there is no pool in 1880), presidents must put in money from hand and
the MAY sell shares if they wish (although these cannot cause a change
of directorship).  If they do not or cannot sell shares, they accrue
debt and add 50% interest on top.

Phil

On 25 July 2011 12:42, Erik Vos <eri...@xs...> wrote:
> I'm working to get the emergency train buying rules right.  Currently, all
> Rails games follow the 1830 rules, and several people have already
> complained about that.
>
> In this stage I do not aim at getting all the details in all games
> completely implemented.
> However, I think I have identified the main options and sorted out how these
> apply to most of the games that we have been working on so far.
>
> The below only applies to companies that must own a train.  That excludes
> 1825.
>
> 1. If a company has no train, it can buy any train on offer from Bank, Pool
> or other companies (at any price) that is has enough cash for.
> It is always obliged to buy a used (Pool) train that it can pay for, if it
> cannot afford a new (IPO) train.
> It is never obliged to buy a train from another company.
> Only if no affordable train can be found this way, the President can and
> indeed must add cash, and the below rules apply.
>
> 2. Must buy the *cheapest* train from Bank or Pool:
> 1830/Kaas, 1856/70, 18AL/GA/TN, 1826: Yes.
> 1835, 18EU/VA/Scan: No.
>
> 3. May buy a train from another company (always up to list price):
> 1830/Kaas, 1835, 18EU/VA/Scan, 1826: Yes.
> 1856/70, 18AL/GA/TN: No.
>
> 4. President may add extra cash above the agreed price (up to list price) if
> buying from another company:
> 1830/Kaas: Yes.  It seems that this even applies if the company has
> sufficient cash for the agreed price.
> 18EU: Yes, but only if the company had exactly zero cash.
> All others: No or N/A.
>
> Any corrections to the above summary?
>
> Any more fine details for these games, and extensions to other games, are
> welcome, but will probably be end up in the for-later-study archive.
> I had a brief look into 1880, but it's not clear to me what the verdicts are
> for this game.
>
> Erik.
>
>
> ------------------------------------------------------------------------------
> Storage Efficiency Calculator
> This modeling tool is based on patent-pending intellectual property that
> has been used successfully in hundreds of IBM storage optimization engage-
> ments, worldwide.  Store less, Store more with what you own, Move data to
> the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

[Rails-devel] Emergency train purchases

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

I'm working to get the emergency train buying rules right.  Currently, all
Rails games follow the 1830 rules, and several people have already
complained about that.

In this stage I do not aim at getting all the details in all games
completely implemented.
However, I think I have identified the main options and sorted out how these
apply to most of the games that we have been working on so far.

The below only applies to companies that must own a train.  That excludes
1825.  

1. If a company has no train, it can buy any train on offer from Bank, Pool
or other companies (at any price) that is has enough cash for. 
It is always obliged to buy a used (Pool) train that it can pay for, if it
cannot afford a new (IPO) train. 
It is never obliged to buy a train from another company.
Only if no affordable train can be found this way, the President can and
indeed must add cash, and the below rules apply.

2. Must buy the *cheapest* train from Bank or Pool:
1830/Kaas, 1856/70, 18AL/GA/TN, 1826: Yes.
1835, 18EU/VA/Scan: No.

3. May buy a train from another company (always up to list price):
1830/Kaas, 1835, 18EU/VA/Scan, 1826: Yes.
1856/70, 18AL/GA/TN: No.

4. President may add extra cash above the agreed price (up to list price) if
buying from another company:
1830/Kaas: Yes.  It seems that this even applies if the company has
sufficient cash for the agreed price.
18EU: Yes, but only if the company had exactly zero cash.
All others: No or N/A.

Any corrections to the above summary? 

Any more fine details for these games, and extensions to other games, are
welcome, but will probably be end up in the for-later-study archive.
I had a brief look into 1880, but it's not clear to me what the verdicts are
for this game.

Erik.

Re: [Rails-devel] Removal of static class variables (git: 8b9df8)

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

On Sun, Jul 24, 2011 at 5:10 AM, Erik Vos <eri...@xs...> wrote:
> See below.
>
>> -----Original Message-----
>> From: Stefan Frey [mailto:ste...@we...]
>> Sent: Sunday, July 24, 2011 9:38 AM
>> To: Development list for Rails: an 18xx game
>> Subject: Re: [Rails-devel] Removal of static class variables (git: 8b9df8)
>>
>> Brett & Erik,
>> I like the discussion, however sometimes for me it is on a too general
> level.
>>
>> I think to decide on how to proceed with the coding it depends on what
>> information will have to be exchanged between clients and server and what
>> the server will actually do. And I have to admit that I currently have
> only
>> vague ideas what the your actual proposals are. But to change my coding
>> behavior you should provide a more concrete plan. I will try to give my
> idea
>> shortly below.
>>
>> >From my point of view the most realistic way is similar to what VASSAL
>> >does,
>> which how I understand it, is mainly exchanging messages and each client
> has
>> a complete model of the game.
>> There are two candidates what to put into those messages: Either the
> actions
>> (like in the save files) or moves (like for the undo/redo stack). Both
> allow to
>> replay the whole game, moves also allow to move backward. Thus on each
>> client a complete Rails game runs (with additional code that restricts
> only
>> entering move for one player) and sends messages to all other clients. If
> this
>> is actually done peer by peer, or one client serving as a message relay or
> a
>> centralized sever in-between does not matter much.
>>
>> All other separations imo require much more efforts in both restructuring
> old
>> code and writing new code.
>
> Exactly. In a way, the AutoSave/Load  feature already brings us pretty close
> to your action-exchange model, except that it's now exchanging complete
> action stacks (saved files) instead of single actions.
>
> My own approach to accomplish a real client/server split would be to work
> bottom-up. First I would refactor all GUI<->engine interchanges to objects
> that are passed between the GameManager and the GameUIManager.  We already
> do this with the action objects, and implementing the action object exchange
> was in fact my first step in this approach.  However, that work is dormant
> now (other wishes and needs have prevailed).  If it ever would be completed,
> the main thing that remains to be done is to serialize these objects and
> build a comms interface in between these managers to transfer the serialized
> objects (and yes, we have initialization issues too).
>
> Brett prefers and has started to work on a top-down approach.
> I don't know where he currently is on that path, and I hope Brett doesn't
> mind that I'm a bit sceptical about his approach, because I believe that he
> will have to deal with the same low-level issues that I have been working
> on, and that those can better be addressed first.
> But equally well, it could turn out to be a nice fit when we meet each other
> somewhere in the middle...
>
>> But most likely the chosen method will depend on the views of the person
>> who volunteers to undertake that task.
>
> That's real life, indeed.
>
> Erik.
>
>> Stefan
>

I don't think the approaches necessarily conflict. With Erik's
approach, we'll get one method of network play (probably earlier than
with my approach) and all of that same work is necessary for what I
want to do.  None of it is lost work.

For me, I'd like to *also* have the ability of the server-side to hold
the state of the game to allow for asynchronous play. This would allow
a wider range of play possibilities.

Historically, I think Erik and I have always preferred to work on
differing sections of the code. ;-)

---Brett.

Re: [Rails-devel] Hex trains support

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

18VA definitely allows to choose when buying from the Pool:

“Trains that are discarded to the Pool revert to their undifferentiated state…” etc.

 

1846: (6.52) “When buying Phase II, III, and IV trains from the bank, either type may be bought.” 

And (6.57) “… turning in excess trains … to the bank…”, so apparently there is no Pool separate from the Bank as far as trains are concerned.

Effectively, 1846 also follows the 18VA rule.

 

18Scan is silent on this subject, and I have mentioned before that, absent any contrary ruling, I would consider the 18VA rules applicable to that game.

 

I don’t have the other games that you mention.   

But if 1812, 1834 and 18EA (mentioned by Chris) are actually different, we must of course support both variations.

 

Erik.

 

From: John A. Tamplin [mailto:ja...@ja...] 
Sent: Sunday, July 24, 2011 4:10 PM
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Hex trains support

 

On Sat, Jul 23, 2011 at 11:43 AM, Erik Vos <eri...@xs...> wrote:

> -----Original Message-----
> From: Chris Shaffer [mailto:chr...@gm...]

> Sent: Saturday, July 23, 2011 4:56 PM
> To: Development list for Rails: an 18xx game

> Subject: Re: [Rails-devel] Hex trains support

> Note that in some games, dual type trains retain their type when discarded
> to the pool.

That's new to me.  Which games are you aware of?

 

Actually, I am not aware of one with dual trains that does allow you to re-choose when buying from the pool.  Other ones I know keep the type in the pool, including 1812, 1834, and 1846.


-- 
John A. Tamplin

Re: [Rails-devel] Code review tools [was: 1880 Patch]

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

On Sun, Jul 24, 2011 at 7:08 AM, John A. Tamplin <ja...@ja...> wrote:
> On Sun, Jul 24, 2011 at 7:39 AM, Erik Vos <eri...@xs...> wrote:
>>
>> ‘Rietveld’ seems to be intended for SVN projects. A similar tool exists
>> for Git named ‘Gerrit’.  Egit supports it.
>
> Yes, sorry -- I forgot that it needs the repository to be svn.  We have
> people using it with git, and the upload code understands git clients
> (whether from svn or our internal repository which is mirrored to svn).
>
>>
>> I don’t have an opinion right now on whether or not we need such a tool.
>>  Sounds to me a bit like overkill, but I may be wrong.
>
> If you spend any time at all looking at patches, you will prefer to look at
> them in something like Rietveld.  Even if you never want to do
> review-before-commit, it is just more convenient to see them there.

I think if we had a larger population of patch submissions or more
stringent patch submission requirements (e.g. N number of upvotes
before acceptance), it might be worthwhile.

Right now, I agree with Erik. It's probably overkill for the size of
project we are.

> --
> John A. Tamplin
>

----Brett.

Re: [Rails-devel] Hex trains support

[Chris S. <chr...@gm...>]

Actually, I checked the 1846 rules and they say that trains discarded to the
pool do not keep their type and can be purchased as either type.

However, I know you can add 18EA to the list of games where trains discarded
keep their type, and as you say 1812 also.  So it's definitely a use case
that needs to be supported.

--
Chris

Please consider the environment before printing this e-mail.


On Sun, Jul 24, 2011 at 7:10 AM, John A. Tamplin <ja...@ja...> wrote:

> On Sat, Jul 23, 2011 at 11:43 AM, Erik Vos <eri...@xs...> wrote:
>
>> > -----Original Message-----
>> > From: Chris Shaffer [mailto:chr...@gm...]
>> > Sent: Saturday, July 23, 2011 4:56 PM
>> > To: Development list for Rails: an 18xx game
>> > Subject: Re: [Rails-devel] Hex trains support
>>
>> > Note that in some games, dual type trains retain their type when
>> discarded
>> > to the pool.
>>
>> That's new to me.  Which games are you aware of?
>
>
> Actually, I am not aware of one with dual trains that does allow you to
> re-choose when buying from the pool.  Other ones I know keep the type in the
> pool, including 1812, 1834, and 1846.
>
> --
> John A. Tamplin
>
>
> ------------------------------------------------------------------------------
> Magic Quadrant for Content-Aware Data Loss Prevention
> Research study explores the data loss prevention market. Includes in-depth
> analysis on the changes within the DLP market, and the criteria used to
> evaluate the strengths and weaknesses of these DLP solutions.
> http://www.accelacomm.com/jaw/sfnl/114/51385063/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] Hex trains support

[John A. T. <ja...@ja...>]

On Sat, Jul 23, 2011 at 11:43 AM, Erik Vos <eri...@xs...> wrote:

> > -----Original Message-----
> > From: Chris Shaffer [mailto:chr...@gm...]
> > Sent: Saturday, July 23, 2011 4:56 PM
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] Hex trains support
>
> > Note that in some games, dual type trains retain their type when
> discarded
> > to the pool.
>
> That's new to me.  Which games are you aware of?


Actually, I am not aware of one with dual trains that does allow you to
re-choose when buying from the pool.  Other ones I know keep the type in the
pool, including 1812, 1834, and 1846.

-- 
John A. Tamplin

Re: [Rails-devel] Code review tools [was: 1880 Patch]

[John A. T. <ja...@ja...>]

On Sun, Jul 24, 2011 at 7:39 AM, Erik Vos <eri...@xs...> wrote:

> ‘Rietveld’ seems to be intended for SVN projects. A similar tool exists for
> Git named ‘Gerrit’.  Egit supports it.****
>
> **
>

Yes, sorry -- I forgot that it needs the repository to be svn.  We have
people using it with git, and the upload code understands git clients
(whether from svn or our internal repository which is mirrored to svn).


> I don’t have an opinion right now on whether or not we need such a tool.
>  Sounds to me a bit like overkill, but I may be wrong.
>

If you spend any time at all looking at patches, you will prefer to look at
them in something like Rietveld.  Even if you never want to do
review-before-commit, it is just more convenient to see them there.

-- 
John A. Tamplin

Re: [Rails-devel] Hex trains support

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

Really?  I have reread the rules three times, but I can't find anything
about how to deal with discarded dual trains, so I would suppose that the
18VA rules (from the same designer) would hold here by default.

 

Erik.

 

From: Chris Shaffer [mailto:chr...@gm...] 
Sent: Sunday, July 24, 2011 7:46 AM
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Hex trains support

 

18Scan


 

--
Chris

Please consider the environment before printing this e-mail.



On Sat, Jul 23, 2011 at 8:43 AM, Erik Vos <eri...@xs...> wrote:

> -----Original Message-----
> From: Chris Shaffer [mailto:chr...@gm...]

> Sent: Saturday, July 23, 2011 4:56 PM
> To: Development list for Rails: an 18xx game

> Subject: Re: [Rails-devel] Hex trains support

> Note that in some games, dual type trains retain their type when discarded
> to the pool.

That's new to me.  Which games are you aware of?

Erik.



----------------------------------------------------------------------------
--
Storage Efficiency Calculator
This modeling tool is based on patent-pending intellectual property that
has been used successfully in hundreds of IBM storage optimization engage-
ments, worldwide.  Store less, Store more with what you own, Move data to

the right place. Try It Now!
http://www.accelacomm.com/jaw/sfnl/114/51427378/

_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

 

Re: [Rails-devel] Removal of static class variables (git: 8b9df8)

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

See below.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Sunday, July 24, 2011 9:38 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Removal of static class variables (git: 8b9df8)
> 
> Brett & Erik,
> I like the discussion, however sometimes for me it is on a too general
level.
> 
> I think to decide on how to proceed with the coding it depends on what
> information will have to be exchanged between clients and server and what
> the server will actually do. And I have to admit that I currently have
only
> vague ideas what the your actual proposals are. But to change my coding
> behavior you should provide a more concrete plan. I will try to give my
idea
> shortly below.
> 
> >From my point of view the most realistic way is similar to what VASSAL
> >does,
> which how I understand it, is mainly exchanging messages and each client
has
> a complete model of the game.
> There are two candidates what to put into those messages: Either the
actions
> (like in the save files) or moves (like for the undo/redo stack). Both
allow to
> replay the whole game, moves also allow to move backward. Thus on each
> client a complete Rails game runs (with additional code that restricts
only
> entering move for one player) and sends messages to all other clients. If
this
> is actually done peer by peer, or one client serving as a message relay or
a
> centralized sever in-between does not matter much.
> 
> All other separations imo require much more efforts in both restructuring
old
> code and writing new code.

Exactly. In a way, the AutoSave/Load  feature already brings us pretty close
to your action-exchange model, except that it's now exchanging complete
action stacks (saved files) instead of single actions.

My own approach to accomplish a real client/server split would be to work
bottom-up. First I would refactor all GUI<->engine interchanges to objects
that are passed between the GameManager and the GameUIManager.  We already
do this with the action objects, and implementing the action object exchange
was in fact my first step in this approach.  However, that work is dormant
now (other wishes and needs have prevailed).  If it ever would be completed,
the main thing that remains to be done is to serialize these objects and
build a comms interface in between these managers to transfer the serialized
objects (and yes, we have initialization issues too).

Brett prefers and has started to work on a top-down approach. 
I don't know where he currently is on that path, and I hope Brett doesn't
mind that I'm a bit sceptical about his approach, because I believe that he
will have to deal with the same low-level issues that I have been working
on, and that those can better be addressed first.
But equally well, it could turn out to be a nice fit when we meet each other
somewhere in the middle...

> But most likely the chosen method will depend on the views of the person
> who volunteers to undertake that task.

That's real life, indeed.
 
Erik.

> Stefan

[Rails-devel] Code review tools [was: 1880 Patch]

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

‘Rietveld’ seems to be intended for SVN projects. A similar tool exists for Git named ‘Gerrit’.  Egit supports it.

 

I don’t have an opinion right now on whether or not we need such a tool.  Sounds to me a bit like overkill, but I may be wrong.

 

The names are interesting, though. Both apparently refer to the same person: the Dutch designer/architect Gerrit Rietveld (1888-1964).

And the Rietveld site says that the tool of that name was based on Mondrian, named after another Dutch artist.

 

That gives me a good feeling… :-)

 

Erik.

 

From: John A. Tamplin [mailto:ja...@ja...] 
Sent: Sunday, July 24, 2011 7:55 AM
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1880 Patch

 

On Sat, Jul 23, 2011 at 4:03 PM, Erik Vos <eri...@xs...> wrote:

The git patch I had created for myself in Egit did have header info.  As it had my full commit text as a Subject, I must have created it from a committed change.

Martin, did you perhaps create your git patch from a working copy?
And do you have set up .gitconfig with at least your name and mail address?

 

Speaking of uploading patches / code reviews, is there any interest in using something like Rietveld <http://code.google.com/p/rietveld/> ?  You can see it in action at http://codereview.appspot.com/4817048/diff/3001/lily/slur-configuration.cc

 

If you are interested, it is trivial to setup an AppEngine instance for free and run one dedicated to Rails.


-- 
John A. Tamplin

[Rails-devel] Rails save files needed

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

To all Rails users:
as the automated game testing works (again), I ask all users of Rails to 
please supply save files of finished or nearly-finished games. I also ask the 
developers for test cases or files of fixed bugs.

Game files for all versions 1.3+ are possible.

For reference I will add the list of games to the wiki page which will 
describe how the automated game testing works.

Please indicate if you are interested if your real name and/or the save file 
itself can be added to that list of the games. 
If not only the game name and version will be listed and the save file will 
only be part of the git repository.

Please send save files directly to my e-mail address and not to the list.

Thanks for your help,
Stefan Frey

Re: [Rails-devel] Removal of static class variables (git: 8b9df8)

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

Brett & Erik,
I like the discussion, however sometimes for me it is on a too general level.

I think to decide on how to proceed with the coding it depends on what 
information will have to be exchanged between clients and server and what the 
server will actually do. And I have to admit that I currently have only vague 
ideas what the your actual proposals are. But to change my coding behavior you 
should provide a more concrete plan. I will try to give my idea shortly below.

From my point of view the most realistic way is similar to what VASSAL does, 
which how I understand it, is mainly exchanging messages and each client has a 
complete model of the game.
There are two candidates what to put into those messages: Either the actions 
(like in the save files) or moves (like for the undo/redo stack). Both allow 
to replay the whole game, moves also allow to move backward. Thus on each 
client a complete Rails game runs (with additional code that restricts only 
entering move for one player) and sends messages to all other clients. If this 
is actually done peer by peer, or one client serving as a message relay or a 
centralized sever in-between does not matter much.

All other separations imo require much more efforts in both restructuring old 
code and writing new code.

But most likely the chosen method will depend on the views of the person who 
volunteers to undertake that task.

Stefan


On Saturday, July 23, 2011 10:07:02 pm brett lentz wrote:
> On Sat, Jul 23, 2011 at 12:54 PM, Erik Vos <eri...@xs...> wrote:
> > See below.
> > 
> >  > -----Original Message-----
> > 
> >> From: brett lentz [mailto:bre...@gm...]
> > 
> >  > Because the clients should take the "authoritative" values for things
> > given to
> > 
> >> it by the server, not whatever arbitrary values somebody decides to put
> > 
> > into
> > 
> >> their own local XML files. Trusting the client to do the right thing on
> > 
> > its own
> > 
> >> makes exploitation far too easy.
> > 
> > That's a good point, but if we go that way, it should occur only once, at
> > the start of the game.
> 
> Yup. I think we agree on the basic idea.
> 
> >> > Always local, in my concept.  Static info does not need to squeezed
> > 
> > through
> > 
> >> the client/server interface.
> >> 
> >> > Unless you want to make the client really dumb, of course.  And
> >> > slower.
> >> 
> >> Over-use of static info also makes supporting multiple threads more
> >> problematic; it increases the likelihood of race conditions and other
> > 
> > difficult-
> > 
> >> to-debug issues. In general, most of the stuff that's currently static
> > 
> > doesn't
> > 
> >> really _need_ to be static.
> > 
> > Apologies, I should *again* have said: "static (as opposed to dynamic)",
> > i.e. never changing.
> > I'm as much against "static (as opposed to instance)" as you are.
> 
> Sounds like we're in violent agreement. ;-)
> 
> IMO, unchanging info should be marked "final". So, it'll be "static
> final" and guaranteed never to change after startup.
> 
> The thing I want to begin reducing is the number of non-final static
> declarations.
> 
> >> The response can be a variety of things, depending on how "thick" or
> > 
> > "thin"
> > 
> >> the client is.
> >> 
> >> 1. It could be a simple "success/failure" response.
> >> 2. It could be success/failure, with an updated client Wallet value.
> >> 3. It could be success/failure, with the current state of every player's
> >> holdings, the whole stock market, or even whole game.
> > 
> > OK.  To be more precise, I think we must distinguish three types of
> > server->client info:
> > 1. The response: what only the previously acting player client gets
> > (success/failure, error message).
> > 2. The broadcast: what *all* clients get (i.e. the initial data, the GUI
> > updates and other state-like info).
> > 3. The prompt (or whatever): what only the next active player gets (i.e.
> > the list of allowed actions).  Or will we allow all players to enter any
> > move, as someone suggested?
> 
> No. You'll note that I included authentication as a part of
> client-server communication in my previous description. We need to be
> able to identify that each player only makes _their_ moves (except for
> administrative overrides).
> 
> However, that shouldn't preclude someone from logging in when it's not
> their own turn and just reviewing the current (read-only) state of the
> game; this is, after all, the exact same use case as playing a "live"
> network game where someone is disconnected for whatever reason and
> reconnects, then waits for their turn.
> 
> > Erik.
> 
> ---Brett.
> 
> ---------------------------------------------------------------------------
> --- Storage Efficiency Calculator
> This modeling tool is based on patent-pending intellectual property that
> has been used successfully in hundreds of IBM storage optimization engage-
> ments, worldwide.  Store less, Store more with what you own, Move data to
> the right place. Try It Now!
> http://www.accelacomm.com/jaw/sfnl/114/51427378/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1880 Patch

[John A. T. <ja...@ja...>]

On Sat, Jul 23, 2011 at 4:03 PM, Erik Vos <eri...@xs...> wrote:

> The git patch I had created for myself in Egit did have header info.  As it
> had my full commit text as a Subject, I must have created it from a
> committed change.
>
> Martin, did you perhaps create your git patch from a working copy?
> And do you have set up .gitconfig with at least your name and mail address?


Speaking of uploading patches / code reviews, is there any interest in using
something like Rietveld <http://code.google.com/p/rietveld/>?  You can see
it in action at
http://codereview.appspot.com/4817048/diff/3001/lily/slur-configuration.cc

If you are interested, it is trivial to setup an AppEngine instance for free
and run one dedicated to Rails.

-- 
John A. Tamplin

Re: [Rails-devel] Hex trains support

[Chris S. <chr...@gm...>]

18Scan

--
Chris

Please consider the environment before printing this e-mail.


On Sat, Jul 23, 2011 at 8:43 AM, Erik Vos <eri...@xs...> wrote:

> > -----Original Message-----
> > From: Chris Shaffer [mailto:chr...@gm...]
> > Sent: Saturday, July 23, 2011 4:56 PM
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] Hex trains support
>
> > Note that in some games, dual type trains retain their type when
> discarded
> > to the pool.
>
> That's new to me.  Which games are you aware of?
>
> Erik.
>
>
>
> ------------------------------------------------------------------------------
> Storage Efficiency Calculator
> This modeling tool is based on patent-pending intellectual property that
> has been used successfully in hundreds of IBM storage optimization engage-
> ments, worldwide.  Store less, Store more with what you own, Move data to
> the right place. Try It Now!
> http://www.accelacomm.com/jaw/sfnl/114/51427378/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Removal of static class variables (git: 8b9df8)

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

On Sat, Jul 23, 2011 at 12:54 PM, Erik Vos <eri...@xs...> wrote:
> See below.
>
>  > -----Original Message-----
>> From: brett lentz [mailto:bre...@gm...]
>
>  > Because the clients should take the "authoritative" values for things
> given to
>> it by the server, not whatever arbitrary values somebody decides to put
> into
>> their own local XML files. Trusting the client to do the right thing on
> its own
>> makes exploitation far too easy.
>
> That's a good point, but if we go that way, it should occur only once, at
> the start of the game.
>

Yup. I think we agree on the basic idea.

>> > Always local, in my concept.  Static info does not need to squeezed
> through
>> the client/server interface.
>> > Unless you want to make the client really dumb, of course.  And slower.
>> >
>>
>> Over-use of static info also makes supporting multiple threads more
>> problematic; it increases the likelihood of race conditions and other
> difficult-
>> to-debug issues. In general, most of the stuff that's currently static
> doesn't
>> really _need_ to be static.
>
> Apologies, I should *again* have said: "static (as opposed to dynamic)",
> i.e. never changing.
> I'm as much against "static (as opposed to instance)" as you are.
>

Sounds like we're in violent agreement. ;-)

IMO, unchanging info should be marked "final". So, it'll be "static
final" and guaranteed never to change after startup.

The thing I want to begin reducing is the number of non-final static
declarations.


>> The response can be a variety of things, depending on how "thick" or
> "thin"
>> the client is.
>>
>> 1. It could be a simple "success/failure" response.
>> 2. It could be success/failure, with an updated client Wallet value.
>> 3. It could be success/failure, with the current state of every player's
>> holdings, the whole stock market, or even whole game.
>
> OK.  To be more precise, I think we must distinguish three types of
> server->client info:
> 1. The response: what only the previously acting player client gets
> (success/failure, error message).
> 2. The broadcast: what *all* clients get (i.e. the initial data, the GUI
> updates and other state-like info).
> 3. The prompt (or whatever): what only the next active player gets (i.e. the
> list of allowed actions).  Or will we allow all players to enter any move,
> as someone suggested?

No. You'll note that I included authentication as a part of
client-server communication in my previous description. We need to be
able to identify that each player only makes _their_ moves (except for
administrative overrides).

However, that shouldn't preclude someone from logging in when it's not
their own turn and just reviewing the current (read-only) state of the
game; this is, after all, the exact same use case as playing a "live"
network game where someone is disconnected for whatever reason and
reconnects, then waits for their turn.

>
> Erik.
>
>

---Brett.

Re: [Rails-devel] 1880 Patch

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

The git patch I had created for myself in Egit did have header info.  As it had my full commit text as a Subject, I must have created it from a committed change.

Martin, did you perhaps create your git patch from a working copy? 
And do you have set up .gitconfig with at least your name and mail address?  

Erik.

> -----Original Message-----
> From: brett lentz [mailto:bre...@gm...]
> Sent: Saturday, July 23, 2011 9:48 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1880 Patch
> 
> Oh... One further note about Git patches:
> 
> I'm not sure if EGit does this, but I know that "git format-patch" does...
> 
> It creates patches with header information about the patch. If this header
> information is retained, it allows the patch to be applied with correct
> attribution to the original author.
> 
> I'm a big fan of making sure proper credit and ownership of work is being
> given. Keeping that header information on your patches helps me do that. :-)
> 
> ---Brett.
> 
> 
> 
> On Sat, Jul 23, 2011 at 12:43 PM, brett lentz <bre...@gm...> wrote:
> > Of course. :-)
> >
> > ---Brett.
> >
> >
> >
> > On Sat, Jul 23, 2011 at 12:28 PM, Erik Vos <eri...@xs...> wrote:
> >> Yes, I had noticed the different patch formats, but overlooked that Egit
> can't yet handle git patched.
> >>
> >> Brett, could you then please apply Martin's patch, that he sent today?
> >>
> >> Erik.
> >>
> >>> -----Original Message-----
> >>> From: Stefan Frey [mailto:ste...@we...]
> >>> Sent: Saturday, July 23, 2011 7:16 PM
> >>> To: Development list for Rails: an 18xx game
> >>> Subject: Re: [Rails-devel] 1880 Patch
> >>>
> >>> Erik & Martin,
> >>> just by chance I came upon this looking for other things:
> >>>
> >>> Inside this tutorial:
> >>> http://unicase.blogspot.com/2011/01/egit-tutorial-for-beginners.html
> >>>
> >>> Take a look at the paragraph Creating Patch:
> >>>
> >>> It states that egit cannot import the git patch format.
> >>> One has to use either a command line tool (do not ask which one) or
> >>> should stay with the normal default diff-patch.
> >>>
> >>> The diff-patch format can be selected in the create patch dialog by
> >>> NOT selecting the git patch format.
> >>>
> >>> However a patch can only contain exactly one commit, thus for
> >>> several commits the commits have to be bundled using rebase before
> >>> creating the patch.
> >>>
> >>> Stefan
> >>>
> >>>
> >>> On Saturday, July 23, 2011 06:37:52 pm Erik Vos wrote:
> >>> > This is a “git” patch, and for some reason this patch does not
> >>> > behave correctly when I’m trying to apply it via Eclipse/Egit:
> >>> >
> >>> >
> >>> >
> >>> > diff --git a/data/1880/CompanyManager.xml
> >>> > b/data/1880/CompanyManager.xml
> >>> >
> >>> > index c02e2d2..cd8dc10 100644
> >>> >
> >>> > --- a/data/1880/CompanyManager.xml
> >>> >
> >>> > +++ b/data/1880/CompanyManager.xml
> >>> >
> >>> > … etc.
> >>> >
> >>> >
> >>> >
> >>> > It creates a subdirectory ‘a’ under the project root, and that’s
> >>> > not correct.
> >>> >
> >>> >
> >>> >
> >>> > Yesterday I tried the same thing to apply some earlier work of
> >>> > myself to the new repo master, and it failed similarly.
> >>> >
> >>> >
> >>> >
> >>> > Does anyone know how to deal with patches in Git/Egit?
> >>> >
> >>> > Perhaps we should use “normal” patches (that don’t have these a/
> >>> > and b/ prefixes)?
> >>> >
> >>> > What are “git” patches useful for at all?
> >>> >
> >>> >
> >>> >
> >>> > Erik.
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > From: Dr....@t-... [mailto:Dr.Martin.Brumm@t-
> >>> online.de]
> >>> > Sent: Saturday, July 23, 2011 5:09 PM
> >>> > To: Rails Development
> >>> > Subject: [Rails-devel] 1880 Patch
> >>> >
> >>> >
> >>> >
> >>> >  hi all,
> >>> >
> >>> >
> >>> >
> >>> > after having a heck of problems with eclipse and [e,j]git i
> >>> > managed to untangle the knot with the external git implementation...
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >     Added changes to the map, introducing the tiles -4008 and
> >>> > -4009 for
> >>> >     the water connections (ferries).
> >>> >
> >>> >     Altered the stockmarket display according to other examples
> >>> > with
> >>> >     colored names for the additional revenue hexes.
> >>> >
> >>> >     Revised the Trains and Phase mechanismns according to the
> >>> > recent
> >>> >     changes done to 1835.
> >>> >
> >>> >
> >>> >
> >>> > <<<<<
> >>> >
> >>> >
> >>> >
> >>> > And yes i'll keep tying to find out why i cant update the local
> >>> > clone from the remote master and make a simple patch file in
> >>> > eclipse from my working branch against an updated local clone...
> >>> >
> >>> >
> >>> >
> >>> > Workflow as intended:
> >>> >
> >>> >
> >>> >
> >>> > Cloned the remote origin into remote/master (local working clone)
> >>> >
> >>> > branched my 1880-devel-branch of the remote/master  (local working
> >>> > clone)
> >>> >
> >>> > edit files
> >>> >
> >>> > commit against 1880 devel branch (so far everything was okay...)
> >>> >
> >>> > updating local working clone via pull/fetch from remote origin
> >>> > (shouldnt overwrite 1880 branch) (didnt work, couldnt get an
> >>> > updated history view of remote/master that was consistent with the
> >>> > history of
> >>> > remote/origin)
> >>> >
> >>> > check for conflicts between 1880 devel branch (.....)
> >>> >
> >>> > draw patch of 1880 devel branch against remote master
> >>> >
> >>> >
> >>> >
> >>> > from here on i choose to merge the 1880 branch with my remote
> >>> > master (that of course in the external git was somehow aligned
> >>> > with the
> >>> > remote/origin...) in the external git and draw a patch against the
> >>> > last state of the remote origin/master...
> >>> >
> >>> > branched a new development branch.(current state of confusion :))
> >>> >
> >>> >
> >>> >
> >>> > I wasnt able to create a small an simple patch from the egit/jgit
> >>> > inside eclipse it created a monster patch over all files even
> >>> > though i had only changed those 6. Probably something to do with
> >>> > the windows/unix CRLF/LF problematic...
> >>> >
> >>> >
> >>> >
> >>> > And yes i if anybody has some advice dont hesitate even if it
> >>> > makes me look like stupid :)
> >>> >
> >>> >
> >>> >
> >>> > Regards Martin
> >>>
> >>> --------------------------------------------------------------------
> >>> ----------
> >>> Storage Efficiency Calculator
> >>> This modeling tool is based on patent-pending intellectual property
> >>> that has been used successfully in hundreds of IBM storage
> >>> optimization engage- ments, worldwide.  Store less, Store more with
> >>> what you own, Move data to the right place. Try It Now!
> >>> http://www.accelacomm.com/jaw/sfnl/114/51427378/
> >>> _______________________________________________
> >>> Rails-devel mailing list
> >>> Rai...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >>
> >>
> >> ---------------------------------------------------------------------
> >> ---------
> >> Storage Efficiency Calculator
> >> This modeling tool is based on patent-pending intellectual property
> >> that has been used successfully in hundreds of IBM storage
> >> optimization engage- ments, worldwide.  Store less, Store more with
> >> what you own, Move data to the right place. Try It Now!
> >> http://www.accelacomm.com/jaw/sfnl/114/51427378/
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >>
> >
> 
> ------------------------------------------------------------------------------
> Storage Efficiency Calculator
> This modeling tool is based on patent-pending intellectual property that has
> been used successfully in hundreds of IBM storage optimization engage-
> ments, worldwide.  Store less, Store more with what you own, Move data to
> the right place. Try It Now!
> http://www.accelacomm.com/jaw/sfnl/114/51427378/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1880 Patch

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

Patch applied.

I needed to convert a bunch of XML files from dos formatting to unix
formatting before it applied cleanly, so that conversion has also been
committed.

---Brett.



On Sat, Jul 23, 2011 at 8:08 AM, Dr....@t-...
<Dr....@t-...> wrote:
>  hi all,
>
>
>
> after having a heck of problems with eclipse and [e,j]git i managed to
> untangle the knot with the external git implementation...
>
>
>
>>>>>
>
>     Added changes to the map, introducing the tiles -4008 and -4009 for
>     the water connections (ferries).
>
>     Altered the stockmarket display according to other examples with
>     colored names for the additional revenue hexes.
>
>     Revised the Trains and Phase mechanismns according to the recent
>     changes done to 1835.
>
>
>
> <<<<<
>
>
>
> And yes i'll keep tying to find out why i cant update the local clone from
> the remote master and make a simple patch file in eclipse from my working
> branch against an updated local clone...
>
>
>
> Workflow as intended:
>
>
>
> Cloned the remote origin into remote/master (local working clone)
>
> branched my 1880-devel-branch of the remote/master  (local working clone)
>
> edit files
>
> commit against 1880 devel branch (so far everything was okay...)
>
> updating local working clone via pull/fetch from remote origin (shouldnt
> overwrite 1880 branch) (didnt work, couldnt get an updated history view of
> remote/master that was consistent with the history of remote/origin)
>
> check for conflicts between 1880 devel branch (.....)
>
> draw patch of 1880 devel branch against remote master
>
>
>
> from here on i choose to merge the 1880 branch with my remote master (that
> of course in the external git was somehow aligned with the remote/origin...)
> in the external git and draw a patch against the last state of the remote
> origin/master...
>
> branched a new development branch.(current state of confusion :))
>
>
>
> I wasnt able to create a small an simple patch from the egit/jgit inside
> eclipse it created a monster patch over all files even though i had only
> changed those 6. Probably something to do with the windows/unix CRLF/LF
> problematic...
>
>
>
> And yes i if anybody has some advice dont hesitate even if it makes me look
> like stupid :)
>
>
>
> Regards Martin
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Storage Efficiency Calculator
> This modeling tool is based on patent-pending intellectual property that
> has been used successfully in hundreds of IBM storage optimization engage-
> ments, worldwide.  Store less, Store more with what you own, Move data to
> the right place. Try It Now!
> http://www.accelacomm.com/jaw/sfnl/114/51427378/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] Removal of static class variables (git: 8b9df8)

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

See below.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]

> >From what I understood from previous discussions is that Erik prefers
> the fat client approach, where "clients" all have a full game back-end
running
> and only pass around actions between them. The server merely acts as a
> message broker.

No.  As I explained, I take an intermediate position, let's call it the
"medium" client.  It knows about all the game objects, but nothing about the
game state, except what info it receives from the server - mainly screen
updates (to all clients) and allowed actions (to the client having the
turn).

 > -----Original Message-----
> From: brett lentz [mailto:bre...@gm...]

 > Because the clients should take the "authoritative" values for things
given to
> it by the server, not whatever arbitrary values somebody decides to put
into
> their own local XML files. Trusting the client to do the right thing on
its own
> makes exploitation far too easy.

That's a good point, but if we go that way, it should occur only once, at
the start of the game.

> > Always local, in my concept.  Static info does not need to squeezed
through
> the client/server interface.
> > Unless you want to make the client really dumb, of course.  And slower.
> >
> 
> Over-use of static info also makes supporting multiple threads more
> problematic; it increases the likelihood of race conditions and other
difficult-
> to-debug issues. In general, most of the stuff that's currently static
doesn't
> really _need_ to be static.

Apologies, I should *again* have said: "static (as opposed to dynamic)",
i.e. never changing. 
I'm as much against "static (as opposed to instance)" as you are.

> The response can be a variety of things, depending on how "thick" or
"thin"
> the client is.
> 
> 1. It could be a simple "success/failure" response.
> 2. It could be success/failure, with an updated client Wallet value.
> 3. It could be success/failure, with the current state of every player's
> holdings, the whole stock market, or even whole game.

OK.  To be more precise, I think we must distinguish three types of
server->client info:
1. The response: what only the previously acting player client gets
(success/failure, error message).
2. The broadcast: what *all* clients get (i.e. the initial data, the GUI
updates and other state-like info).
3. The prompt (or whatever): what only the next active player gets (i.e. the
list of allowed actions).  Or will we allow all players to enter any move,
as someone suggested?

Erik. 

Re: [Rails-devel] 1880 Patch

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

Oh... One further note about Git patches:

I'm not sure if EGit does this, but I know that "git format-patch" does...

It creates patches with header information about the patch. If this
header information is retained, it allows the patch to be applied with
correct attribution to the original author.

I'm a big fan of making sure proper credit and ownership of work is
being given. Keeping that header information on your patches helps me
do that. :-)

---Brett.



On Sat, Jul 23, 2011 at 12:43 PM, brett lentz <bre...@gm...> wrote:
> Of course. :-)
>
> ---Brett.
>
>
>
> On Sat, Jul 23, 2011 at 12:28 PM, Erik Vos <eri...@xs...> wrote:
>> Yes, I had noticed the different patch formats, but overlooked that Egit can't yet handle git patched.
>>
>> Brett, could you then please apply Martin's patch, that he sent today?
>>
>> Erik.
>>
>>> -----Original Message-----
>>> From: Stefan Frey [mailto:ste...@we...]
>>> Sent: Saturday, July 23, 2011 7:16 PM
>>> To: Development list for Rails: an 18xx game
>>> Subject: Re: [Rails-devel] 1880 Patch
>>>
>>> Erik & Martin,
>>> just by chance I came upon this looking for other things:
>>>
>>> Inside this tutorial:
>>> http://unicase.blogspot.com/2011/01/egit-tutorial-for-beginners.html
>>>
>>> Take a look at the paragraph Creating Patch:
>>>
>>> It states that egit cannot import the git patch format.
>>> One has to use either a command line tool (do not ask which one) or should
>>> stay with the normal default diff-patch.
>>>
>>> The diff-patch format can be selected in the create patch dialog by NOT
>>> selecting the git patch format.
>>>
>>> However a patch can only contain exactly one commit, thus for several
>>> commits the commits have to be bundled using rebase before creating the
>>> patch.
>>>
>>> Stefan
>>>
>>>
>>> On Saturday, July 23, 2011 06:37:52 pm Erik Vos wrote:
>>> > This is a “git” patch, and for some reason this patch does not behave
>>> > correctly when I’m trying to apply it via Eclipse/Egit:
>>> >
>>> >
>>> >
>>> > diff --git a/data/1880/CompanyManager.xml
>>> > b/data/1880/CompanyManager.xml
>>> >
>>> > index c02e2d2..cd8dc10 100644
>>> >
>>> > --- a/data/1880/CompanyManager.xml
>>> >
>>> > +++ b/data/1880/CompanyManager.xml
>>> >
>>> > … etc.
>>> >
>>> >
>>> >
>>> > It creates a subdirectory ‘a’ under the project root, and that’s not
>>> > correct.
>>> >
>>> >
>>> >
>>> > Yesterday I tried the same thing to apply some earlier work of myself
>>> > to the new repo master, and it failed similarly.
>>> >
>>> >
>>> >
>>> > Does anyone know how to deal with patches in Git/Egit?
>>> >
>>> > Perhaps we should use “normal” patches (that don’t have these a/ and
>>> > b/ prefixes)?
>>> >
>>> > What are “git” patches useful for at all?
>>> >
>>> >
>>> >
>>> > Erik.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > From: Dr....@t-... [mailto:Dr.Martin.Brumm@t-
>>> online.de]
>>> > Sent: Saturday, July 23, 2011 5:09 PM
>>> > To: Rails Development
>>> > Subject: [Rails-devel] 1880 Patch
>>> >
>>> >
>>> >
>>> >  hi all,
>>> >
>>> >
>>> >
>>> > after having a heck of problems with eclipse and [e,j]git i managed to
>>> > untangle the knot with the external git implementation...
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >     Added changes to the map, introducing the tiles -4008 and -4009 for
>>> >     the water connections (ferries).
>>> >
>>> >     Altered the stockmarket display according to other examples with
>>> >     colored names for the additional revenue hexes.
>>> >
>>> >     Revised the Trains and Phase mechanismns according to the recent
>>> >     changes done to 1835.
>>> >
>>> >
>>> >
>>> > <<<<<
>>> >
>>> >
>>> >
>>> > And yes i'll keep tying to find out why i cant update the local clone
>>> > from the remote master and make a simple patch file in eclipse from my
>>> > working branch against an updated local clone...
>>> >
>>> >
>>> >
>>> > Workflow as intended:
>>> >
>>> >
>>> >
>>> > Cloned the remote origin into remote/master (local working clone)
>>> >
>>> > branched my 1880-devel-branch of the remote/master  (local working
>>> > clone)
>>> >
>>> > edit files
>>> >
>>> > commit against 1880 devel branch (so far everything was okay...)
>>> >
>>> > updating local working clone via pull/fetch from remote origin
>>> > (shouldnt overwrite 1880 branch) (didnt work, couldnt get an updated
>>> > history view of remote/master that was consistent with the history of
>>> > remote/origin)
>>> >
>>> > check for conflicts between 1880 devel branch (.....)
>>> >
>>> > draw patch of 1880 devel branch against remote master
>>> >
>>> >
>>> >
>>> > from here on i choose to merge the 1880 branch with my remote master
>>> > (that of course in the external git was somehow aligned with the
>>> > remote/origin...) in the external git and draw a patch against the
>>> > last state of the remote origin/master...
>>> >
>>> > branched a new development branch.(current state of confusion :))
>>> >
>>> >
>>> >
>>> > I wasnt able to create a small an simple patch from the egit/jgit
>>> > inside eclipse it created a monster patch over all files even though i
>>> > had only changed those 6. Probably something to do with the
>>> > windows/unix CRLF/LF problematic...
>>> >
>>> >
>>> >
>>> > And yes i if anybody has some advice dont hesitate even if it makes me
>>> > look like stupid :)
>>> >
>>> >
>>> >
>>> > Regards Martin
>>>
>>> ------------------------------------------------------------------------------
>>> Storage Efficiency Calculator
>>> This modeling tool is based on patent-pending intellectual property that has
>>> been used successfully in hundreds of IBM storage optimization engage-
>>> ments, worldwide.  Store less, Store more with what you own, Move data to
>>> the right place. Try It Now!
>>> http://www.accelacomm.com/jaw/sfnl/114/51427378/
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Storage Efficiency Calculator
>> This modeling tool is based on patent-pending intellectual property that
>> has been used successfully in hundreds of IBM storage optimization engage-
>> ments, worldwide.  Store less, Store more with what you own, Move data to
>> the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>

Re: [Rails-devel] 1880 Patch

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

Of course. :-)

---Brett.



On Sat, Jul 23, 2011 at 12:28 PM, Erik Vos <eri...@xs...> wrote:
> Yes, I had noticed the different patch formats, but overlooked that Egit can't yet handle git patched.
>
> Brett, could you then please apply Martin's patch, that he sent today?
>
> Erik.
>
>> -----Original Message-----
>> From: Stefan Frey [mailto:ste...@we...]
>> Sent: Saturday, July 23, 2011 7:16 PM
>> To: Development list for Rails: an 18xx game
>> Subject: Re: [Rails-devel] 1880 Patch
>>
>> Erik & Martin,
>> just by chance I came upon this looking for other things:
>>
>> Inside this tutorial:
>> http://unicase.blogspot.com/2011/01/egit-tutorial-for-beginners.html
>>
>> Take a look at the paragraph Creating Patch:
>>
>> It states that egit cannot import the git patch format.
>> One has to use either a command line tool (do not ask which one) or should
>> stay with the normal default diff-patch.
>>
>> The diff-patch format can be selected in the create patch dialog by NOT
>> selecting the git patch format.
>>
>> However a patch can only contain exactly one commit, thus for several
>> commits the commits have to be bundled using rebase before creating the
>> patch.
>>
>> Stefan
>>
>>
>> On Saturday, July 23, 2011 06:37:52 pm Erik Vos wrote:
>> > This is a “git” patch, and for some reason this patch does not behave
>> > correctly when I’m trying to apply it via Eclipse/Egit:
>> >
>> >
>> >
>> > diff --git a/data/1880/CompanyManager.xml
>> > b/data/1880/CompanyManager.xml
>> >
>> > index c02e2d2..cd8dc10 100644
>> >
>> > --- a/data/1880/CompanyManager.xml
>> >
>> > +++ b/data/1880/CompanyManager.xml
>> >
>> > … etc.
>> >
>> >
>> >
>> > It creates a subdirectory ‘a’ under the project root, and that’s not
>> > correct.
>> >
>> >
>> >
>> > Yesterday I tried the same thing to apply some earlier work of myself
>> > to the new repo master, and it failed similarly.
>> >
>> >
>> >
>> > Does anyone know how to deal with patches in Git/Egit?
>> >
>> > Perhaps we should use “normal” patches (that don’t have these a/ and
>> > b/ prefixes)?
>> >
>> > What are “git” patches useful for at all?
>> >
>> >
>> >
>> > Erik.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > From: Dr....@t-... [mailto:Dr.Martin.Brumm@t-
>> online.de]
>> > Sent: Saturday, July 23, 2011 5:09 PM
>> > To: Rails Development
>> > Subject: [Rails-devel] 1880 Patch
>> >
>> >
>> >
>> >  hi all,
>> >
>> >
>> >
>> > after having a heck of problems with eclipse and [e,j]git i managed to
>> > untangle the knot with the external git implementation...
>> >
>> >
>> >
>> >
>> >
>> >
>> >     Added changes to the map, introducing the tiles -4008 and -4009 for
>> >     the water connections (ferries).
>> >
>> >     Altered the stockmarket display according to other examples with
>> >     colored names for the additional revenue hexes.
>> >
>> >     Revised the Trains and Phase mechanismns according to the recent
>> >     changes done to 1835.
>> >
>> >
>> >
>> > <<<<<
>> >
>> >
>> >
>> > And yes i'll keep tying to find out why i cant update the local clone
>> > from the remote master and make a simple patch file in eclipse from my
>> > working branch against an updated local clone...
>> >
>> >
>> >
>> > Workflow as intended:
>> >
>> >
>> >
>> > Cloned the remote origin into remote/master (local working clone)
>> >
>> > branched my 1880-devel-branch of the remote/master  (local working
>> > clone)
>> >
>> > edit files
>> >
>> > commit against 1880 devel branch (so far everything was okay...)
>> >
>> > updating local working clone via pull/fetch from remote origin
>> > (shouldnt overwrite 1880 branch) (didnt work, couldnt get an updated
>> > history view of remote/master that was consistent with the history of
>> > remote/origin)
>> >
>> > check for conflicts between 1880 devel branch (.....)
>> >
>> > draw patch of 1880 devel branch against remote master
>> >
>> >
>> >
>> > from here on i choose to merge the 1880 branch with my remote master
>> > (that of course in the external git was somehow aligned with the
>> > remote/origin...) in the external git and draw a patch against the
>> > last state of the remote origin/master...
>> >
>> > branched a new development branch.(current state of confusion :))
>> >
>> >
>> >
>> > I wasnt able to create a small an simple patch from the egit/jgit
>> > inside eclipse it created a monster patch over all files even though i
>> > had only changed those 6. Probably something to do with the
>> > windows/unix CRLF/LF problematic...
>> >
>> >
>> >
>> > And yes i if anybody has some advice dont hesitate even if it makes me
>> > look like stupid :)
>> >
>> >
>> >
>> > Regards Martin
>>
>> ------------------------------------------------------------------------------
>> Storage Efficiency Calculator
>> This modeling tool is based on patent-pending intellectual property that has
>> been used successfully in hundreds of IBM storage optimization engage-
>> ments, worldwide.  Store less, Store more with what you own, Move data to
>> the right place. Try It Now!
>> http://www.accelacomm.com/jaw/sfnl/114/51427378/
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> Storage Efficiency Calculator
> This modeling tool is based on patent-pending intellectual property that
> has been used successfully in hundreds of IBM storage optimization engage-
> ments, worldwide.  Store less, Store more with what you own, Move data to
> the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] 1880 Patch

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

Yes, I had noticed the different patch formats, but overlooked that Egit can't yet handle git patched.

Brett, could you then please apply Martin's patch, that he sent today?

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Saturday, July 23, 2011 7:16 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1880 Patch
> 
> Erik & Martin,
> just by chance I came upon this looking for other things:
> 
> Inside this tutorial:
> http://unicase.blogspot.com/2011/01/egit-tutorial-for-beginners.html
> 
> Take a look at the paragraph Creating Patch:
> 
> It states that egit cannot import the git patch format.
> One has to use either a command line tool (do not ask which one) or should
> stay with the normal default diff-patch.
> 
> The diff-patch format can be selected in the create patch dialog by NOT
> selecting the git patch format.
> 
> However a patch can only contain exactly one commit, thus for several
> commits the commits have to be bundled using rebase before creating the
> patch.
> 
> Stefan
> 
> 
> On Saturday, July 23, 2011 06:37:52 pm Erik Vos wrote:
> > This is a “git” patch, and for some reason this patch does not behave
> > correctly when I’m trying to apply it via Eclipse/Egit:
> >
> >
> >
> > diff --git a/data/1880/CompanyManager.xml
> > b/data/1880/CompanyManager.xml
> >
> > index c02e2d2..cd8dc10 100644
> >
> > --- a/data/1880/CompanyManager.xml
> >
> > +++ b/data/1880/CompanyManager.xml
> >
> > … etc.
> >
> >
> >
> > It creates a subdirectory ‘a’ under the project root, and that’s not
> > correct.
> >
> >
> >
> > Yesterday I tried the same thing to apply some earlier work of myself
> > to the new repo master, and it failed similarly.
> >
> >
> >
> > Does anyone know how to deal with patches in Git/Egit?
> >
> > Perhaps we should use “normal” patches (that don’t have these a/ and
> > b/ prefixes)?
> >
> > What are “git” patches useful for at all?
> >
> >
> >
> > Erik.
> >
> >
> >
> >
> >
> >
> >
> > From: Dr....@t-... [mailto:Dr.Martin.Brumm@t-
> online.de]
> > Sent: Saturday, July 23, 2011 5:09 PM
> > To: Rails Development
> > Subject: [Rails-devel] 1880 Patch
> >
> >
> >
> >  hi all,
> >
> >
> >
> > after having a heck of problems with eclipse and [e,j]git i managed to
> > untangle the knot with the external git implementation...
> >
> >
> >
> >
> >
> >
> >     Added changes to the map, introducing the tiles -4008 and -4009 for
> >     the water connections (ferries).
> >
> >     Altered the stockmarket display according to other examples with
> >     colored names for the additional revenue hexes.
> >
> >     Revised the Trains and Phase mechanismns according to the recent
> >     changes done to 1835.
> >
> >
> >
> > <<<<<
> >
> >
> >
> > And yes i'll keep tying to find out why i cant update the local clone
> > from the remote master and make a simple patch file in eclipse from my
> > working branch against an updated local clone...
> >
> >
> >
> > Workflow as intended:
> >
> >
> >
> > Cloned the remote origin into remote/master (local working clone)
> >
> > branched my 1880-devel-branch of the remote/master  (local working
> > clone)
> >
> > edit files
> >
> > commit against 1880 devel branch (so far everything was okay...)
> >
> > updating local working clone via pull/fetch from remote origin
> > (shouldnt overwrite 1880 branch) (didnt work, couldnt get an updated
> > history view of remote/master that was consistent with the history of
> > remote/origin)
> >
> > check for conflicts between 1880 devel branch (.....)
> >
> > draw patch of 1880 devel branch against remote master
> >
> >
> >
> > from here on i choose to merge the 1880 branch with my remote master
> > (that of course in the external git was somehow aligned with the
> > remote/origin...) in the external git and draw a patch against the
> > last state of the remote origin/master...
> >
> > branched a new development branch.(current state of confusion :))
> >
> >
> >
> > I wasnt able to create a small an simple patch from the egit/jgit
> > inside eclipse it created a monster patch over all files even though i
> > had only changed those 6. Probably something to do with the
> > windows/unix CRLF/LF problematic...
> >
> >
> >
> > And yes i if anybody has some advice dont hesitate even if it makes me
> > look like stupid :)
> >
> >
> >
> > Regards Martin
> 
> ------------------------------------------------------------------------------
> Storage Efficiency Calculator
> This modeling tool is based on patent-pending intellectual property that has
> been used successfully in hundreds of IBM storage optimization engage-
> ments, worldwide.  Store less, Store more with what you own, Move data to
> the right place. Try It Now!
> http://www.accelacomm.com/jaw/sfnl/114/51427378/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel