rails-devel — List for discussion of Rails development

Re: [Rails-devel] Change: Tiles are excluded from upgrade panel if no valid orientation exists

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

Stefan:
> the only thing missing now is that the image shows the first possible allowed rotation

This functionality is now available in master.

-- Frederick

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

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

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

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

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

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

Re: [Rails-devel] FW: Fwd: 1830 RSM Fix included

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

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

Re: [Rails-devel] FW: Fwd: 1830 RSM Fix included

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

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

Re: [Rails-devel] FW: Fwd: 1830 RSM Fix included

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

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

Re: [Rails-devel] FW: Fwd: 1830 RSM Fix included

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

On Wed, Feb 1, 2012 at 8:28 AM, Stefan Frey <ste...@we...> wrote:
> Frederick:
> I am not a git-expert myself, but you could either trust Brett who uses
> git in his day-job (at least what I understood) or check some sources on
> the Internet:
>

Correct. I've been using git on a daily basis for 3-4 years now. I
recently switched employers, and now git is an even bigger part of my
daily work life. ;-)

> Especially this q&a on stackoverflow:
> http://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions
>
> Shows the workflow using rebase in the first listing (and yours in the
> second).
>
> You still merge your features, however you FIRST rebase your new feature
> on top of the master repo.
>

This is correct.

The whole idea behind rebase is to re-align your feature branch's
history so that the diff is *ONLY* your changes. That way, when you
merge the branches, you're not considering someone else's work and
being forced to resolve any merge conflicts for work you didn't create
(and probably aren't the expert on).

To do this, git rewinds your feature branch back to the common point
in both branch's history, then it replays the remote branch's changes
onto your feature branch, and THEN it re-applies your local commits on
top of the new, updated history.

Under most circumstances, this is a good thing. This allows you to see
whether some new commits have made your local commits un-merge-able.
You get to resolve the merge conflicts in your local feature branch
*before* merging your local feature branch into the publicly published
branches.

> Maybe Brett can shed even more light on this issues (again).
>
> Stefan
>

---Brett.

>
> On 02/01/2012 02:06 PM, Frederick Weld wrote:
>> Not regarding this specific issue but more as a request for alignment
>> regarding hotfix procedure:
>>
>> I'm not a GIT expert but this is what I would do to provide a hotfix
>> for a release branch (1.6.x - locally available remote tracking branch
>> assumed):
>>
>> git checkout -b Hotfix-xyz 1.6.x
>> ...do changes...
>> git commit -a -m "Hotfix-xyz..."
>> git checkout 1.6.x
>> git pull
>> git merge --no-ff Hotfix-xyz
>> git push
>> git checkout master
>> git pull
>> git merge --no-ff Hotfix-xyz
>> git push
>> git branch -D Hotfix-xyz
>>
>> To me, switching to auto-rebase is very dangerous if we are working on
>> several remote tracking branches and might pull from one of these
>> local branches to the other. If not (or if there is only one remote
>> tracking branch as for Erik), switching to auto-rebase appears to 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] FW: Fwd: 1830 RSM Fix included

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

Frederick:
I am not a git-expert myself, but you could either trust Brett who uses
git in his day-job (at least what I understood) or check some sources on 
the Internet:

Especially this q&a on stackoverflow:
http://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions

Shows the workflow using rebase in the first listing (and yours in the 
second).

You still merge your features, however you FIRST rebase your new feature 
on top of the master repo.

Maybe Brett can shed even more light on this issues (again).

Stefan


On 02/01/2012 02:06 PM, Frederick Weld wrote:
> Not regarding this specific issue but more as a request for alignment
> regarding hotfix procedure:
>
> I'm not a GIT expert but this is what I would do to provide a hotfix
> for a release branch (1.6.x - locally available remote tracking branch
> assumed):
>
> git checkout -b Hotfix-xyz 1.6.x
> ...do changes...
> git commit -a -m "Hotfix-xyz..."
> git checkout 1.6.x
> git pull
> git merge --no-ff Hotfix-xyz
> git push
> git checkout master
> git pull
> git merge --no-ff Hotfix-xyz
> git push
> git branch -D Hotfix-xyz
>
> To me, switching to auto-rebase is very dangerous if we are working on
> several remote tracking branches and might pull from one of these
> local branches to the other. If not (or if there is only one remote
> tracking branch as for Erik), switching to auto-rebase appears to 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] FW: Fwd: 1830 RSM Fix included

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

Not regarding this specific issue but more as a request for alignment
regarding hotfix procedure:

I'm not a GIT expert but this is what I would do to provide a hotfix
for a release branch (1.6.x - locally available remote tracking branch
assumed):

git checkout -b Hotfix-xyz 1.6.x
...do changes...
git commit -a -m "Hotfix-xyz..."
git checkout 1.6.x
git pull
git merge --no-ff Hotfix-xyz
git push
git checkout master
git pull
git merge --no-ff Hotfix-xyz
git push
git branch -D Hotfix-xyz

To me, switching to auto-rebase is very dangerous if we are working on
several remote tracking branches and might pull from one of these
local branches to the other. If not (or if there is only one remote
tracking branch as for Erik), switching to auto-rebase appears to be
ok.

--Frederick

Re: [Rails-devel] FW: Fwd: 1830 RSM Fix included

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

Erik,
Yes I remember: I doubt that it was your intention ;-)

However I still surprised that it was possible that
code written by Frederick ended up under a commit from you.
And this commit was not a merge commit, but the bug-fix release.

Maybe you did amend the merge commit with your fix or other way round?
Brett do you have a story that explains it?

Stefan


On 02/01/2012 10:27 AM, Erik Vos wrote:
> Stefan,
>
> As I explained before:  I had accidentally pulled [from master] while checked out in my local nonmodal branch, which had some unmerged commits.  The merge occurred when I was rebasing everything back in order.
> If you know a way to protect myself against such mistakes, please tell me.  I don't know if autosetuprebase will fix that, but I have added it anyway.
>
> BTW my git pull and push are set up for master only.  I'm keeping all other remote branches out of the way.
>
> Erik.
>
>> -----Original Message-----
>> From: Stefan Frey [mailto:ste...@we...]
>> Sent: Wednesday, February 01, 2012 8:08 AM
>> To: rai...@li...
>> Subject: Re: [Rails-devel] FW: Fwd: 1830 RSM Fix included
>>
>> Erik:
>> the patch works perfectly: However you the commit you used to fix it is
>> tainted by your merge:
>>
>> If you check a26c986 it changes 15 files and contains many changes which
>> where actually from Frederick.
>>
>> My guess it that is somehow related to the fact that you merge your changes
>> instead of using rebase to add them at the end of the repository?
>>
>> Have you set the git config branch.autosetuprebase=always?
>> This was recommended by Brett Lentz and avoids the frequent merges you
>> have used recently.
>>
>> For current case I will recreate a commit which only contains your fix for the
>> 1.6.x branch.
>>
>> Stefan
>>
>> On 01/31/2012 10:25 PM, Erik Vos wrote:
>>> I just have pushed a different fix: two statements had to be swapped.
>>>
>>> Martin, your fix would only allow selling 20%, but in fact the president can
>> also sell only 10% if he wants.
>>>
>>> Erik.
>>>
>>> From: Dr....@t-... [mailto:Dr.Martin.Brumm@t-
>> online.de]
>>> Sent: Tuesday, January 31, 2012 9:15 PM
>>> To: Development list for Rails: an 18xx game; Erik Vos; Stefan Frey
>>> Subject: Re: [Rails-devel] Fwd: 1830 RSM Fix included
>>>
>>> Hi Stefan&Erik,
>>> i believe the following small fix solves that problem, Please run your
>>> usual test scenarios :) And maybe we should add that save file as a test !
>>> Regards,
>>> Martin
>>> diff --git a/rails/game/StockRound.java b/rails/game/StockRound.java
>>> index 037d2cc..25d05ce 100644
>>> --- a/rails/game/StockRound.java
>>> +++ b/rails/game/StockRound.java
>>> @@ -464,7 +464,7 @@
>>>                 */
>>>                // Take care for max. 4 share units per share
>>>                compName = company.getName();
>>> -            int[] shareCountPerUnit =
>> playerPortfolio.getCertificateTypeCountsPerCompany(compName, false);
>>> +            int[] shareCountPerUnit =
>> playerPortfolio.getCertificateTypeCountsPerCompany(compName,
>> true);//Martin: we need to make sure we find the president only share to
>> sell in the next step!
>>>                // Check the price. If a cert was sold before this turn, the original
>> price is still valid.
>>>                price = getCurrentSellPrice(company);
>>>
>>> Von: Stefan Frey<ste...@we...>
>>> An: Erik Vos<eri...@xs...>
>>> Cc: an 18xx game<rai...@li...>
>>> Betreff: [Rails-devel] Fwd: 1830 RSM
>>> Datum: Tue, 31 Jan 2012 16:15:26 +0100
>>> Erik:
>>> I forward you a report of a potentially critical bug: It does not
>>> allow selling the director of the NYNH given that the operating
>>> director owns the president share only and 2 other players have 20%
>>> each and Pool having 30% only.
>>>
>>> This bug can be reproduced back to 1.5.3, unfortunately the save file
>>> is not fully loadable under 1.5.2.
>>>
>>> I suspect this is related to the changes for 1835 at that time, I have
>>> to admit that I cannot fully understand the code used to create the
>>> actions for selling, so you might be in a better position to find this bug.
>>>
>>> Thanks,
>>> Stefan
>>>
>>>
>>> -------- Original Message --------
>>> Subject: Fwd: 1830 RSM
>>> Date: Tue, 31 Jan 2012 09:30:48 -0500
>>> From: Bob Probst
>>> To: stefan.frey
>>>
>>> Stefan, a friend of mine found this issue. I haven't confirmed it yet
>>> but he's pretty thorough.
>>>
>>> I'm sure you can contact him directly if you have any questions
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: "Ing. Antonio Baracca"
>>> Date: Tue, 31 Jan 2012 14:53:37 +0100
>>> Subject: Fwd: 1830 RSM
>>> To: Bob Probst
>>> Cc: Palmiro Matteini
>>>
>>> Hi Bob,
>>> we have found a major bug on the 1830 module.
>>> The current player cannot sell 10% of NYNH from his president
>>> certificate (remaining so with only 10% of NYNH and shifting the
>>> presidency of the corporation).
>>> I attach a saved file of the current 1830 game with the bug point.
>>> I have seen you are currently in contact with programmers.
>>> Can you please report to them this bug?
>>> Thank you in advance.
>>> Regards
>>> Antonio
>>>
>>>
>>>
>>> Inizio messaggio inoltrato:
>>>
>>>> Da: "Palmiro Matteini"
>>>> Data: 31 gennaio 2012 14.23.26 GMT+01.00
>>>> A: "Ing. Antonio Baracca"
>>>> Oggetto: Re: 1830 RSM
>>>>
>>>> Eccolo.
>>>> Ciao.
>>>>
>>>> Palmiro Matteini
>>>> pma...@om...
>>>> ----- Original Message -----
>>>> From: Ing. Antonio Baracca
>>>> To: Palmiro Matteini
>>>> Sent: Tuesday, January 31, 2012 11:46 AM
>>>> Subject: Re: 1830 RSM
>>>>
>>>> Mandami la salvata che ci guardo
>>>>
>>>>
>>>> Antonio Baracca
>>>> ant...@ti...
>>>>
>>>> Il giorno 31/gen/2012, alle ore 09:28, "Palmiro Matteini" ha scritto:
>>>>
>>>>> Ciao Antonio.
>>>>> Nella partita che stiamo facendo con Rail in ASGS, è successa una cosa
>> strana.
>>>>> Glauco ha venduto azioni della NYNH tenendosi solo il certificato della
>> presidenza del 20%.
>>>>> Al giro successivo c'erano altri giocatori che avevano il 20% e nel bank
>> pool c'era il 30%.
>>>>> Il programma stranamente non gli ha permesso di vendere il certificato
>> della presidenza.
>>>>> C'è un buco nel programma ?
>>>>> Ciao.
>>>>>
>>>>> Palmiro Matteini
>>>>> pma...@om...
>>>
>>> Antonio Baracca
>>> ant...@gm...
>>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> -------- 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] FW: Fwd: 1830 RSM Fix included

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

Martin:
Sorry did not push the fix, waited for the new release to be complete.
Stefan

On 02/01/2012 08:18 AM, Dr....@t-... wrote:
> Hi Stefan & Erik,
>
> i dont see the fixes in 1.6.x just in master ? Is that correct and
> intended ?
>
> Regards,
>
> Martin
>
> *Von:* Stefan Frey <ste...@we...>
> *An:* rai...@li...
> *Betreff:* Re: [Rails-devel] FW: Fwd: 1830 RSM Fix included
> *Datum:* Wed, 01 Feb 2012 08:08:14 +0100
>
> Erik:
> the patch works perfectly: However you the commit you used
> to fix it is tainted by your merge:
>
> If you check a26c986 it changes 15 files and contains many
> changes which where actually from Frederick.
>
> My guess it that is somehow related to the fact that you merge
> your changes instead of using rebase to add them at the end of the
> repository?
>
> Have you set the git config branch.autosetuprebase=always?
> This was recommended by Brett Lentz and avoids the frequent merges
> you have used recently.
>
> For current case I will recreate a commit which only contains your fix
> for the 1.6.x branch.
>
> Stefan
>
> On 01/31/2012 10:25 PM, Erik Vos wrote:
>  > I just have pushed a different fix: two statements had to be swapped.
>  >
>  > Martin, your fix would only allow selling 20%, but in fact the
> president can also sell only 10% if he wants.
>  >
>  > Erik.
>  >
>  > From: Dr....@t-... [mailto:Dr....@t-...]
>  > Sent: Tuesday, January 31, 2012 9:15 PM
>  > To: Development list for Rails: an 18xx game; Erik Vos; Stefan Frey
>  > Subject: Re: [Rails-devel] Fwd: 1830 RSM Fix included
>  >
>  > Hi Stefan&Erik,
>  > i believe the following small fix solves that problem,
>  > Please run your usual test scenarios :) And maybe we should add that
> save file as a test !
>  > Regards,
>  > Martin
>  > diff --git a/rails/game/StockRound.java b/rails/game/StockRound.java
>  > index 037d2cc..25d05ce 100644
>  > --- a/rails/game/StockRound.java
>  > +++ b/rails/game/StockRound.java
>  > @@ -464,7 +464,7 @@
>  > */
>  > // Take care for max. 4 share units per share
>  > compName = company.getName();
>  > - int[] shareCountPerUnit =
> playerPortfolio.getCertificateTypeCountsPerCompany(compName, false);
>  > + int[] shareCountPerUnit =
> playerPortfolio.getCertificateTypeCountsPerCompany(compName,
> true);//Martin: we need to make sure we find the president only share to
> sell in the next step!
>  > // Check the price. If a cert was sold before this turn, the original
> price is still valid.
>  > price = getCurrentSellPrice(company);
>  >
>  > Von: Stefan Frey
>  > An: Erik Vos
>  > Cc: an 18xx game
>  > Betreff: [Rails-devel] Fwd: 1830 RSM
>  > Datum: Tue, 31 Jan 2012 16:15:26 +0100
>  > Erik:
>  > I forward you a report of a potentially critical bug: It does not allow
>  > selling the director of the NYNH given that the operating director owns
>  > the president share only and 2 other players have 20% each and Pool
>  > having 30% only.
>  >
>  > This bug can be reproduced back to 1.5.3, unfortunately the save file is
>  > not fully loadable under 1.5.2.
>  >
>  > I suspect this is related to the changes for 1835 at that time, I have
>  > to admit that I cannot fully understand the code used to create the
>  > actions for selling, so you might be in a better position to find
> this bug.
>  >
>  > Thanks,
>  > Stefan
>  >
>  >
>  > -------- Original Message --------
>  > Subject: Fwd: 1830 RSM
>  > Date: Tue, 31 Jan 2012 09:30:48 -0500
>  > From: Bob Probst
>  > To: stefan.frey
>  >
>  > Stefan, a friend of mine found this issue. I haven't confirmed it yet
>  > but he's pretty thorough.
>  >
>  > I'm sure you can contact him directly if you have any questions
>  >
>  >
>  > ---------- Forwarded message ----------
>  > From: "Ing. Antonio Baracca"
>  > Date: Tue, 31 Jan 2012 14:53:37 +0100
>  > Subject: Fwd: 1830 RSM
>  > To: Bob Probst
>  > Cc: Palmiro Matteini
>  >
>  > Hi Bob,
>  > we have found a major bug on the 1830 module.
>  > The current player cannot sell 10% of NYNH from his president
>  > certificate (remaining so with only 10% of NYNH and shifting the
>  > presidency of the corporation).
>  > I attach a saved file of the current 1830 game with the bug point.
>  > I have seen you are currently in contact with programmers.
>  > Can you please report to them this bug?
>  > Thank you in advance.
>  > Regards
>  > Antonio
>  >
>  >
>  >
>  > Inizio messaggio inoltrato:
>  >
>  >> Da: "Palmiro Matteini"
>  >> Data: 31 gennaio 2012 14.23.26 GMT+01.00
>  >> A: "Ing. Antonio Baracca"
>  >> Oggetto: Re: 1830 RSM
>  >>
>  >> Eccolo.
>  >> Ciao.
>  >>
>  >> Palmiro Matteini
>  >> pma...@om...
>  >> ----- Original Message -----
>  >> From: Ing. Antonio Baracca
>  >> To: Palmiro Matteini
>  >> Sent: Tuesday, January 31, 2012 11:46 AM
>  >> Subject: Re: 1830 RSM
>  >>
>  >> Mandami la salvata che ci guardo
>  >>
>  >>
>  >> Antonio Baracca
>  >> ant...@ti...
>  >>
>  >> Il giorno 31/gen/2012, alle ore 09:28, "Palmiro Matteini" ha scritto:
>  >>
>  >>> Ciao Antonio.
>  >>> Nella partita che stiamo facendo con Rail in ASGS, è successa una
> cosa strana.
>  >>> Glauco ha venduto azioni della NYNH tenendosi solo il certificato
> della presidenza del 20%.
>  >>> Al giro successivo c'erano altri giocatori che avevano il 20% e nel
> bank pool c'era il 30%.
>  >>> Il programma stranamente non gli ha permesso di vendere il
> certificato della presidenza.
>  >>> C'è un buco nel programma ?
>  >>> Ciao.
>  >>>
>  >>> Palmiro Matteini
>  >>> pma...@om...
>  >
>  > Antonio Baracca
>  > ant...@gm...
>  >
>  >
>  >
>  >
> ------------------------------------------------------------------------------
>  > 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

[Rails-devel] Release Rails 1.6.2 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.2/

This release fixes one sole bug: It was not possible to sell a single
President share. Ongoing and new games should update.
The bug effects all versions since Rails 1.5.2.

Thanks to Erik Vos for fixing the bug and Bill Probst for reporting.

Re: [Rails-devel] FW: Fwd: 1830 RSM Fix included

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

Stefan,

As I explained before:  I had accidentally pulled [from master] while checked out in my local nonmodal branch, which had some unmerged commits.  The merge occurred when I was rebasing everything back in order.
If you know a way to protect myself against such mistakes, please tell me.  I don't know if autosetuprebase will fix that, but I have added it anyway.

BTW my git pull and push are set up for master only.  I'm keeping all other remote branches out of the way.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Wednesday, February 01, 2012 8:08 AM
> To: rai...@li...
> Subject: Re: [Rails-devel] FW: Fwd: 1830 RSM Fix included
> 
> Erik:
> the patch works perfectly: However you the commit you used to fix it is
> tainted by your merge:
> 
> If you check a26c986 it changes 15 files and contains many changes which
> where actually from Frederick.
> 
> My guess it that is somehow related to the fact that you merge your changes
> instead of using rebase to add them at the end of the repository?
> 
> Have you set the git config branch.autosetuprebase=always?
> This was recommended by Brett Lentz and avoids the frequent merges you
> have used recently.
> 
> For current case I will recreate a commit which only contains your fix for the
> 1.6.x branch.
> 
> Stefan
> 
> On 01/31/2012 10:25 PM, Erik Vos wrote:
> > I just have pushed a different fix: two statements had to be swapped.
> >
> > Martin, your fix would only allow selling 20%, but in fact the president can
> also sell only 10% if he wants.
> >
> > Erik.
> >
> > From: Dr....@t-... [mailto:Dr.Martin.Brumm@t-
> online.de]
> > Sent: Tuesday, January 31, 2012 9:15 PM
> > To: Development list for Rails: an 18xx game; Erik Vos; Stefan Frey
> > Subject: Re: [Rails-devel] Fwd: 1830 RSM Fix included
> >
> > Hi Stefan&Erik,
> > i believe the following small fix solves that problem, Please run your
> > usual test scenarios :) And maybe we should add that save file as a test !
> > Regards,
> > Martin
> > diff --git a/rails/game/StockRound.java b/rails/game/StockRound.java
> > index 037d2cc..25d05ce 100644
> > --- a/rails/game/StockRound.java
> > +++ b/rails/game/StockRound.java
> > @@ -464,7 +464,7 @@
> >                */
> >               // Take care for max. 4 share units per share
> >               compName = company.getName();
> > -            int[] shareCountPerUnit =
> playerPortfolio.getCertificateTypeCountsPerCompany(compName, false);
> > +            int[] shareCountPerUnit =
> playerPortfolio.getCertificateTypeCountsPerCompany(compName,
> true);//Martin: we need to make sure we find the president only share to
> sell in the next step!
> >               // Check the price. If a cert was sold before this turn, the original
> price is still valid.
> >               price = getCurrentSellPrice(company);
> >
> > Von: Stefan Frey<ste...@we...>
> > An: Erik Vos<eri...@xs...>
> > Cc: an 18xx game<rai...@li...>
> > Betreff: [Rails-devel] Fwd: 1830 RSM
> > Datum: Tue, 31 Jan 2012 16:15:26 +0100
> > Erik:
> > I forward you a report of a potentially critical bug: It does not
> > allow selling the director of the NYNH given that the operating
> > director owns the president share only and 2 other players have 20%
> > each and Pool having 30% only.
> >
> > This bug can be reproduced back to 1.5.3, unfortunately the save file
> > is not fully loadable under 1.5.2.
> >
> > I suspect this is related to the changes for 1835 at that time, I have
> > to admit that I cannot fully understand the code used to create the
> > actions for selling, so you might be in a better position to find this bug.
> >
> > Thanks,
> > Stefan
> >
> >
> > -------- Original Message --------
> > Subject: Fwd: 1830 RSM
> > Date: Tue, 31 Jan 2012 09:30:48 -0500
> > From: Bob Probst
> > To: stefan.frey
> >
> > Stefan, a friend of mine found this issue. I haven't confirmed it yet
> > but he's pretty thorough.
> >
> > I'm sure you can contact him directly if you have any questions
> >
> >
> > ---------- Forwarded message ----------
> > From: "Ing. Antonio Baracca"
> > Date: Tue, 31 Jan 2012 14:53:37 +0100
> > Subject: Fwd: 1830 RSM
> > To: Bob Probst
> > Cc: Palmiro Matteini
> >
> > Hi Bob,
> > we have found a major bug on the 1830 module.
> > The current player cannot sell 10% of NYNH from his president
> > certificate (remaining so with only 10% of NYNH and shifting the
> > presidency of the corporation).
> > I attach a saved file of the current 1830 game with the bug point.
> > I have seen you are currently in contact with programmers.
> > Can you please report to them this bug?
> > Thank you in advance.
> > Regards
> > Antonio
> >
> >
> >
> > Inizio messaggio inoltrato:
> >
> >> Da: "Palmiro Matteini"
> >> Data: 31 gennaio 2012 14.23.26 GMT+01.00
> >> A: "Ing. Antonio Baracca"
> >> Oggetto: Re: 1830 RSM
> >>
> >> Eccolo.
> >> Ciao.
> >>
> >> Palmiro Matteini
> >> pma...@om...
> >> ----- Original Message -----
> >> From: Ing. Antonio Baracca
> >> To: Palmiro Matteini
> >> Sent: Tuesday, January 31, 2012 11:46 AM
> >> Subject: Re: 1830 RSM
> >>
> >> Mandami la salvata che ci guardo
> >>
> >>
> >> Antonio Baracca
> >> ant...@ti...
> >>
> >> Il giorno 31/gen/2012, alle ore 09:28, "Palmiro Matteini" ha scritto:
> >>
> >>> Ciao Antonio.
> >>> Nella partita che stiamo facendo con Rail in ASGS, è successa una cosa
> strana.
> >>> Glauco ha venduto azioni della NYNH tenendosi solo il certificato della
> presidenza del 20%.
> >>> Al giro successivo c'erano altri giocatori che avevano il 20% e nel bank
> pool c'era il 30%.
> >>> Il programma stranamente non gli ha permesso di vendere il certificato
> della presidenza.
> >>> C'è un buco nel programma ?
> >>> Ciao.
> >>>
> >>> Palmiro Matteini
> >>> pma...@om...
> >
> > Antonio Baracca
> > ant...@gm...
> >
> >
> >
> > ----------------------------------------------------------------------
> > -------- 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] FW: Fwd: 1830 RSM Fix included

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

Sorry, I had wanted but forgot to add that I’m only working with master.

 

Erik.

 

From: Dr....@t-... [mailto:Dr....@t-...] 
Sent: Wednesday, February 01, 2012 8:18 AM
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] FW: Fwd: 1830 RSM Fix included

 

Hi Stefan & Erik,

 

i dont see the fixes in 1.6.x just in master ? Is that correct and intended ?

 

Regards,

Martin

 

Von: Stefan Frey <ste...@we...>
An: rai...@li...
Betreff: Re: [Rails-devel] FW: Fwd: 1830 RSM Fix included
Datum: Wed, 01 Feb 2012 08:08:14 +0100

Erik:
the patch works perfectly: However you the commit you used
to fix it is tainted by your merge:

If you check a26c986 it changes 15 files and contains many
changes which where actually from Frederick.

My guess it that is somehow related to the fact that you merge
your changes instead of using rebase to add them at the end of the 
repository?

Have you set the git config branch.autosetuprebase=always?
This was recommended by Brett Lentz and avoids the frequent merges
you have used recently.

For current case I will recreate a commit which only contains your fix 
for the 1.6.x branch.

Stefan

On 01/31/2012 10:25 PM, Erik Vos wrote:
> I just have pushed a different fix: two statements had to be swapped.
>
> Martin, your fix would only allow selling 20%, but in fact the president can also sell only 10% if he wants.
>
> Erik.
>
> From: Dr....@t-... [mailto:Dr....@t-...]
> Sent: Tuesday, January 31, 2012 9:15 PM
> To: Development list for Rails: an 18xx game; Erik Vos; Stefan Frey
> Subject: Re: [Rails-devel] Fwd: 1830 RSM Fix included
>
> Hi Stefan&Erik,
> i believe the following small fix solves that problem,
> Please run your usual test scenarios :) And maybe we should add that save file as a test !
> Regards,
> Martin
> diff --git a/rails/game/StockRound.java b/rails/game/StockRound.java
> index 037d2cc..25d05ce 100644
> --- a/rails/game/StockRound.java
> +++ b/rails/game/StockRound.java
> @@ -464,7 +464,7 @@
> */
> // Take care for max. 4 share units per share
> compName = company.getName();
> - int[] shareCountPerUnit = playerPortfolio.getCertificateTypeCountsPerCompany(compName, false);
> + int[] shareCountPerUnit = playerPortfolio.getCertificateTypeCountsPerCompany(compName, true);//Martin: we need to make sure we find the president only share to sell in the next step!
> // Check the price. If a cert was sold before this turn, the original price is still valid.
> price = getCurrentSellPrice(company);
>
> Von: Stefan Frey
> An: Erik Vos
> Cc: an 18xx game
> Betreff: [Rails-devel] Fwd: 1830 RSM
> Datum: Tue, 31 Jan 2012 16:15:26 +0100
> Erik:
> I forward you a report of a potentially critical bug: It does not allow
> selling the director of the NYNH given that the operating director owns
> the president share only and 2 other players have 20% each and Pool
> having 30% only.
>
> This bug can be reproduced back to 1.5.3, unfortunately the save file is
> not fully loadable under 1.5.2.
>
> I suspect this is related to the changes for 1835 at that time, I have
> to admit that I cannot fully understand the code used to create the
> actions for selling, so you might be in a better position to find this bug.
>
> Thanks,
> Stefan
>
>
> -------- Original Message --------
> Subject: Fwd: 1830 RSM
> Date: Tue, 31 Jan 2012 09:30:48 -0500
> From: Bob Probst
> To: stefan.frey
>
> Stefan, a friend of mine found this issue. I haven't confirmed it yet
> but he's pretty thorough.
>
> I'm sure you can contact him directly if you have any questions
>
>
> ---------- Forwarded message ----------
> From: "Ing. Antonio Baracca"
> Date: Tue, 31 Jan 2012 14:53:37 +0100
> Subject: Fwd: 1830 RSM
> To: Bob Probst
> Cc: Palmiro Matteini
>
> Hi Bob,
> we have found a major bug on the 1830 module.
> The current player cannot sell 10% of NYNH from his president
> certificate (remaining so with only 10% of NYNH and shifting the
> presidency of the corporation).
> I attach a saved file of the current 1830 game with the bug point.
> I have seen you are currently in contact with programmers.
> Can you please report to them this bug?
> Thank you in advance.
> Regards
> Antonio
>
>
>
> Inizio messaggio inoltrato:
>
>> Da: "Palmiro Matteini"
>> Data: 31 gennaio 2012 14.23.26 GMT+01.00
>> A: "Ing. Antonio Baracca"
>> Oggetto: Re: 1830 RSM
>>
>> Eccolo.
>> Ciao.
>>
>> Palmiro Matteini
>> pma...@om...
>> ----- Original Message -----
>> From: Ing. Antonio Baracca
>> To: Palmiro Matteini
>> Sent: Tuesday, January 31, 2012 11:46 AM
>> Subject: Re: 1830 RSM
>>
>> Mandami la salvata che ci guardo
>>
>>
>> Antonio Baracca
>> ant...@ti...
>>
>> Il giorno 31/gen/2012, alle ore 09:28, "Palmiro Matteini" ha scritto:
>>
>>> Ciao Antonio.
>>> Nella partita che stiamo facendo con Rail in ASGS, è successa una cosa strana.
>>> Glauco ha venduto azioni della NYNH tenendosi solo il certificato della presidenza del 20%.
>>> Al giro successivo c'erano altri giocatori che avevano il 20% e nel bank pool c'era il 30%.
>>> Il programma stranamente non gli ha permesso di vendere il certificato della presidenza.
>>> C'è un buco nel programma ?
>>> Ciao.
>>>
>>> Palmiro Matteini
>>> pma...@om...
>
> Antonio Baracca
> ant...@gm...
>
>
>
> ------------------------------------------------------------------------------
> 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] FW: Fwd: 1830 RSM Fix included

[<Dr....@t-...>]

Hi Stefan & Erik, 

	i dont see the fixes in 1.6.x just in master ? Is that correct and
intended ? 

	Regards, 

	Martin  

	  Von: Stefan Frey <ste...@we...>
 An: rai...@li...
 Betreff: Re: [Rails-devel] FW:  Fwd: 1830 RSM Fix included
 Datum: Wed, 01 Feb 2012 08:08:14 +0100

 Erik:
 the patch works perfectly: However you the commit you used
 to fix it is tainted by your merge:

 If you check a26c986 it changes 15 files and contains many
 changes which where actually from Frederick.

 My guess it that is somehow related to the fact that you merge
 your changes instead of using rebase to add them at the end of the 
 repository?

 Have you set the git config branch.autosetuprebase=always?
 This was recommended by Brett Lentz and avoids the frequent merges
 you have used recently.

 For current case I will recreate a commit which only contains your
fix 
 for the 1.6.x branch.

 Stefan

 On 01/31/2012 10:25 PM, Erik Vos wrote:
 > I just have pushed a different fix: two statements had to be
swapped.
 >
 > Martin, your fix would only allow selling 20%, but in fact the
president can also sell only 10% if he wants.
 >
 > Erik.
 >
 > From: Dr....@t-...
[mailto:Dr....@t-...]
 > Sent: Tuesday, January 31, 2012 9:15 PM
 > To: Development list for Rails: an 18xx game; Erik Vos; Stefan Frey
 > Subject: Re: [Rails-devel] Fwd: 1830 RSM Fix included
 >
 > Hi Stefan&Erik,
 > i believe the following small fix solves that problem,
 > Please run your usual test scenarios :) And maybe we should add
that save file as a test !
 > Regards,
 > Martin
 > diff --git a/rails/game/StockRound.java
b/rails/game/StockRound.java
 > index 037d2cc..25d05ce 100644
 > --- a/rails/game/StockRound.java
 > +++ b/rails/game/StockRound.java
 > @@ -464,7 +464,7 @@
 >                */
 >               // Take care for max. 4 share units per share
 >               compName = company.getName();
 > -            int[] shareCountPerUnit =
playerPortfolio.getCertificateTypeCountsPerCompany(compName, false);
 > +            int[] shareCountPerUnit =
playerPortfolio.getCertificateTypeCountsPerCompany(compName,
true);//Martin: we need to make sure we find the president only share
to sell in the next step!
 >               // Check the price. If a cert was sold before this
turn, the original price is still valid.
 >               price = getCurrentSellPrice(company);
 >
 > Von: Stefan Frey
 > An: Erik Vos
 > Cc: an 18xx game
 > Betreff: [Rails-devel] Fwd: 1830 RSM
 > Datum: Tue, 31 Jan 2012 16:15:26 +0100
 > Erik:
 > I forward you a report of a potentially critical bug: It does not
allow
 > selling the director of the NYNH given that the operating director
owns
 > the president share only and 2 other players have 20% each and Pool
 > having 30% only.
 >
 > This bug can be reproduced back to 1.5.3, unfortunately the save
file is
 > not fully loadable under 1.5.2.
 >
 > I suspect this is related to the changes for 1835 at that time, I
have
 > to admit that I cannot fully understand the code used to create the
 > actions for selling, so you might be in a better position to find
this bug.
 >
 > Thanks,
 > Stefan
 >
 >
 > -------- Original Message --------
 > Subject: Fwd: 1830 RSM
 > Date: Tue, 31 Jan 2012 09:30:48 -0500
 > From: Bob Probst
 > To: stefan.frey
 >
 > Stefan, a friend of mine found this issue. I haven't confirmed it
yet
 > but he's pretty thorough.
 >
 > I'm sure you can contact him directly if you have any questions
 >
 >
 > ---------- Forwarded message ----------
 > From: "Ing. Antonio Baracca"
 > Date: Tue, 31 Jan 2012 14:53:37 +0100
 > Subject: Fwd: 1830 RSM
 > To: Bob Probst
 > Cc: Palmiro Matteini
 >
 > Hi Bob,
 > we have found a major bug on the 1830 module.
 > The current player cannot sell 10% of NYNH from his president
 > certificate (remaining so with only 10% of NYNH and shifting the
 > presidency of the corporation).
 > I attach a saved file of the current 1830 game with the bug point.
 > I have seen you are currently in contact with programmers.
 > Can you please report to them this bug?
 > Thank you in advance.
 > Regards
 > Antonio
 >
 >
 >
 > Inizio messaggio inoltrato:
 >
 >> Da: "Palmiro Matteini"
 >> Data: 31 gennaio 2012 14.23.26 GMT+01.00
 >> A: "Ing. Antonio Baracca"
 >> Oggetto: Re: 1830 RSM
 >>
 >> Eccolo.
 >> Ciao.
 >>
 >> Palmiro Matteini
 >> pma...@om...
 >> ----- Original Message -----
 >> From: Ing. Antonio Baracca
 >> To: Palmiro Matteini
 >> Sent: Tuesday, January 31, 2012 11:46 AM
 >> Subject: Re: 1830 RSM
 >>
 >> Mandami la salvata che ci guardo
 >>
 >>
 >> Antonio Baracca
 >> ant...@ti...
 >>
 >> Il giorno 31/gen/2012, alle ore 09:28, "Palmiro Matteini" ha
scritto:
 >>
 >>> Ciao Antonio.
 >>> Nella partita che stiamo facendo con Rail in ASGS, è successa
una cosa strana.
 >>> Glauco ha venduto azioni della NYNH tenendosi solo il certificato
della presidenza del 20%.
 >>> Al giro successivo c'erano altri giocatori che avevano il 20% e
nel bank pool c'era il 30%.
 >>> Il programma stranamente non gli ha permesso di vendere il
certificato della presidenza.
 >>> C'è un buco nel programma ?
 >>> Ciao.
 >>>
 >>> Palmiro Matteini
 >>> pma...@om...
 >
 > Antonio Baracca
 > ant...@gm...
 >
 >
 >
 >
------------------------------------------------------------------------------
 > 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] FW: Fwd: 1830 RSM Fix included

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

Erik:
the patch works perfectly: However you the commit you used
to fix it is tainted by your merge:

If you check a26c986 it changes 15 files and contains many
changes which where actually from Frederick.

My guess it that is somehow related to the fact that you merge
your changes instead of using rebase to add them at the end of the 
repository?

Have you set the git config branch.autosetuprebase=always?
This was recommended by Brett Lentz and avoids the frequent merges
you have used recently.

For current case I will recreate a commit which only contains your fix 
for the 1.6.x branch.

Stefan

On 01/31/2012 10:25 PM, Erik Vos wrote:
> I just have pushed a different fix: two statements had to be swapped.
>
> Martin, your fix would only allow selling 20%, but in fact the president can also sell only 10% if he wants.
>
> Erik.
>
> From: Dr....@t-... [mailto:Dr....@t-...]
> Sent: Tuesday, January 31, 2012 9:15 PM
> To: Development list for Rails: an 18xx game; Erik Vos; Stefan Frey
> Subject: Re: [Rails-devel] Fwd: 1830 RSM Fix included
>
> Hi Stefan&Erik,
> i believe the following small fix solves that problem,
> Please run your usual test scenarios :) And maybe we should add that save file as a test !
> Regards,
> Martin
> diff --git a/rails/game/StockRound.java b/rails/game/StockRound.java
> index 037d2cc..25d05ce 100644
> --- a/rails/game/StockRound.java
> +++ b/rails/game/StockRound.java
> @@ -464,7 +464,7 @@
>                */
>               // Take care for max. 4 share units per share
>               compName = company.getName();
> -            int[] shareCountPerUnit = playerPortfolio.getCertificateTypeCountsPerCompany(compName, false);
> +            int[] shareCountPerUnit = playerPortfolio.getCertificateTypeCountsPerCompany(compName, true);//Martin: we need to make sure we find the president only share to sell in the next step!
>               // Check the price. If a cert was sold before this turn, the original price is still valid.
>               price = getCurrentSellPrice(company);
>
> Von: Stefan Frey<ste...@we...>
> An: Erik Vos<eri...@xs...>
> Cc: an 18xx game<rai...@li...>
> Betreff: [Rails-devel] Fwd: 1830 RSM
> Datum: Tue, 31 Jan 2012 16:15:26 +0100
> Erik:
> I forward you a report of a potentially critical bug: It does not allow
> selling the director of the NYNH given that the operating director owns
> the president share only and 2 other players have 20% each and Pool
> having 30% only.
>
> This bug can be reproduced back to 1.5.3, unfortunately the save file is
> not fully loadable under 1.5.2.
>
> I suspect this is related to the changes for 1835 at that time, I have
> to admit that I cannot fully understand the code used to create the
> actions for selling, so you might be in a better position to find this bug.
>
> Thanks,
> Stefan
>
>
> -------- Original Message --------
> Subject: Fwd: 1830 RSM
> Date: Tue, 31 Jan 2012 09:30:48 -0500
> From: Bob Probst
> To: stefan.frey
>
> Stefan, a friend of mine found this issue. I haven't confirmed it yet
> but he's pretty thorough.
>
> I'm sure you can contact him directly if you have any questions
>
>
> ---------- Forwarded message ----------
> From: "Ing. Antonio Baracca"
> Date: Tue, 31 Jan 2012 14:53:37 +0100
> Subject: Fwd: 1830 RSM
> To: Bob Probst
> Cc: Palmiro Matteini
>
> Hi Bob,
> we have found a major bug on the 1830 module.
> The current player cannot sell 10% of NYNH from his president
> certificate (remaining so with only 10% of NYNH and shifting the
> presidency of the corporation).
> I attach a saved file of the current 1830 game with the bug point.
> I have seen you are currently in contact with programmers.
> Can you please report to them this bug?
> Thank you in advance.
> Regards
> Antonio
>
>
>
> Inizio messaggio inoltrato:
>
>> Da: "Palmiro Matteini"
>> Data: 31 gennaio 2012 14.23.26 GMT+01.00
>> A: "Ing. Antonio Baracca"
>> Oggetto: Re: 1830 RSM
>>
>> Eccolo.
>> Ciao.
>>
>> Palmiro Matteini
>> pma...@om...
>> ----- Original Message -----
>> From: Ing. Antonio Baracca
>> To: Palmiro Matteini
>> Sent: Tuesday, January 31, 2012 11:46 AM
>> Subject: Re: 1830 RSM
>>
>> Mandami la salvata che ci guardo
>>
>>
>> Antonio Baracca
>> ant...@ti...
>>
>> Il giorno 31/gen/2012, alle ore 09:28, "Palmiro Matteini" ha scritto:
>>
>>> Ciao Antonio.
>>> Nella partita che stiamo facendo con Rail in ASGS, è successa una cosa strana.
>>> Glauco ha venduto azioni della NYNH tenendosi solo il certificato della presidenza del 20%.
>>> Al giro successivo c'erano altri giocatori che avevano il 20% e nel bank pool c'era il 30%.
>>> Il programma stranamente non gli ha permesso di vendere il certificato della presidenza.
>>> C'è un buco nel programma ?
>>> Ciao.
>>>
>>> Palmiro Matteini
>>> pma...@om...
>
> Antonio Baracca
> ant...@gm...
>
>
>
> ------------------------------------------------------------------------------
> 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] FW: Fwd: 1830 RSM Fix included

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

I just have pushed a different fix: two statements had to be swapped.

Martin, your fix would only allow selling 20%, but in fact the president can also sell only 10% if he wants.

Erik.

From: Dr....@t-... [mailto:Dr....@t-...] 
Sent: Tuesday, January 31, 2012 9:15 PM
To: Development list for Rails: an 18xx game; Erik Vos; Stefan Frey
Subject: Re: [Rails-devel] Fwd: 1830 RSM Fix included

Hi Stefan &Erik,
i believe the following small fix solves that problem,
Please run your usual test scenarios :) And maybe we should add that save file as a test !
Regards,
Martin
diff --git a/rails/game/StockRound.java b/rails/game/StockRound.java
index 037d2cc..25d05ce 100644
--- a/rails/game/StockRound.java
+++ b/rails/game/StockRound.java
@@ -464,7 +464,7 @@
              */
             // Take care for max. 4 share units per share
             compName = company.getName();
-            int[] shareCountPerUnit = playerPortfolio.getCertificateTypeCountsPerCompany(compName, false);
+            int[] shareCountPerUnit = playerPortfolio.getCertificateTypeCountsPerCompany(compName, true);//Martin: we need to make sure we find the president only share to sell in the next step!
             // Check the price. If a cert was sold before this turn, the original price is still valid.
             price = getCurrentSellPrice(company);
 
Von: Stefan Frey <ste...@we...>
An: Erik Vos <eri...@xs...>
Cc: an 18xx game <rai...@li...>
Betreff: [Rails-devel] Fwd: 1830 RSM
Datum: Tue, 31 Jan 2012 16:15:26 +0100
Erik:
I forward you a report of a potentially critical bug: It does not allow 
selling the director of the NYNH given that the operating director owns 
the president share only and 2 other players have 20% each and Pool 
having 30% only.

This bug can be reproduced back to 1.5.3, unfortunately the save file is 
not fully loadable under 1.5.2.

I suspect this is related to the changes for 1835 at that time, I have 
to admit that I cannot fully understand the code used to create the 
actions for selling, so you might be in a better position to find this bug.

Thanks,
Stefan


-------- Original Message --------
Subject: Fwd: 1830 RSM
Date: Tue, 31 Jan 2012 09:30:48 -0500
From: Bob Probst 
To: stefan.frey 

Stefan, a friend of mine found this issue. I haven't confirmed it yet
but he's pretty thorough.

I'm sure you can contact him directly if you have any questions


---------- Forwarded message ----------
From: "Ing. Antonio Baracca" 
Date: Tue, 31 Jan 2012 14:53:37 +0100
Subject: Fwd: 1830 RSM
To: Bob Probst 
Cc: Palmiro Matteini 

Hi Bob,
we have found a major bug on the 1830 module.
The current player cannot sell 10% of NYNH from his president
certificate (remaining so with only 10% of NYNH and shifting the
presidency of the corporation).
I attach a saved file of the current 1830 game with the bug point.
I have seen you are currently in contact with programmers.
Can you please report to them this bug?
Thank you in advance.
Regards
Antonio



Inizio messaggio inoltrato:

> Da: "Palmiro Matteini" 
> Data: 31 gennaio 2012 14.23.26 GMT+01.00
> A: "Ing. Antonio Baracca" 
> Oggetto: Re: 1830 RSM
>
> Eccolo.
> Ciao.
>
> Palmiro Matteini
> pma...@om...
> ----- Original Message -----
> From: Ing. Antonio Baracca
> To: Palmiro Matteini
> Sent: Tuesday, January 31, 2012 11:46 AM
> Subject: Re: 1830 RSM
>
> Mandami la salvata che ci guardo
>
>
> Antonio Baracca
> ant...@ti...
>
> Il giorno 31/gen/2012, alle ore 09:28, "Palmiro Matteini" ha scritto:
>
>> Ciao Antonio.
>> Nella partita che stiamo facendo con Rail in ASGS, è successa una cosa strana.
>> Glauco ha venduto azioni della NYNH tenendosi solo il certificato della presidenza del 20%.
>> Al giro successivo c'erano altri giocatori che avevano il 20% e nel bank pool c'era il 30%.
>> Il programma stranamente non gli ha permesso di vendere il certificato della presidenza.
>> C'è un buco nel programma ?
>> Ciao.
>>
>> Palmiro Matteini
>> pma...@om...

Antonio Baracca
ant...@gm...
 

Re: [Rails-devel] Fwd: 1830 RSM Fix included

[<Dr....@t-...>]

Hi Stefan &Erik,  i believe the following small fix solves that
problem,  Please run your usual test scenarios :) And maybe we should
add that save file as a test !  Regards, Martin  diff --git
a/rails/game/StockRound.java b/rails/game/StockRound.java
index 037d2cc..25d05ce 100644
--- a/rails/game/StockRound.java
+++ b/rails/game/StockRound.java
@@ -464,7 +464,7 @@
              */
             // Take care for max. 4 share units per share
             compName = company.getName();
-            int[] shareCountPerUnit =
playerPortfolio.getCertificateTypeCountsPerCompany(compName, false);
+            int[] shareCountPerUnit =
playerPortfolio.getCertificateTypeCountsPerCompany(compName,
true);//Martin: we need to make sure we find the president only share
to sell in the next step!
             // Check the price. If a cert was sold before this turn,
the original price is still valid.
             price = getCurrentSellPrice(company);   

	  Von: Stefan Frey <ste...@we...>
 An: Erik Vos <eri...@xs...>
 Cc: an 18xx game <rai...@li...>
 Betreff: [Rails-devel] Fwd: 1830 RSM
 Datum: Tue, 31 Jan 2012 16:15:26 +0100

 Erik:
 I forward you a report of a potentially critical bug: It does not
allow 
 selling the director of the NYNH given that the operating director
owns 
 the president share only and 2 other players have 20% each and Pool 
 having 30% only.

 This bug can be reproduced back to 1.5.3, unfortunately the save file
is 
 not fully loadable under 1.5.2.

 I suspect this is related to the changes for 1835 at that time, I
have 
 to admit that I cannot fully understand the code used to create the 
 actions for selling, so you might be in a better position to find
this bug.

 Thanks,
 Stefan

 -------- Original Message --------
 Subject: Fwd: 1830 RSM
 Date: Tue, 31 Jan 2012 09:30:48 -0500
 From: Bob Probst 
 To: stefan.frey 

 Stefan, a friend of mine found this issue.  I haven't confirmed it
yet
 but he's pretty thorough.

 I'm sure you can contact him directly if you have any questions

 ---------- Forwarded message ----------
 From: "Ing. Antonio Baracca" 
 Date: Tue, 31 Jan 2012 14:53:37 +0100
 Subject: Fwd: 1830 RSM
 To: Bob Probst 
 Cc: Palmiro Matteini 

 Hi Bob,
 we have found a major bug on the 1830 module.
 The current player cannot sell 10% of NYNH from his president
 certificate (remaining so with only 10% of NYNH and shifting the
 presidency of the corporation).
 I attach a saved file of the current 1830 game with the bug point.
 I have seen you are currently in contact with programmers.
 Can you please report to them this bug?
 Thank you in advance.
 Regards
 Antonio

 Inizio messaggio inoltrato:

 > Da: "Palmiro Matteini" 
 > Data: 31 gennaio 2012 14.23.26 GMT+01.00
 > A: "Ing. Antonio Baracca" 
 > Oggetto: Re: 1830 RSM
 >
 > Eccolo.
 > Ciao.
 >
 > Palmiro Matteini
 > pma...@om...
 > ----- Original Message -----
 > From: Ing. Antonio Baracca
 > To: Palmiro Matteini
 > Sent: Tuesday, January 31, 2012 11:46 AM
 > Subject: Re: 1830 RSM
 >
 > Mandami la salvata che ci guardo
 >
 >
 > Antonio Baracca
 > ant...@ti...
 >
 > Il giorno 31/gen/2012, alle ore 09:28, "Palmiro Matteini"  ha
scritto:
 >
 >> Ciao Antonio.
 >> Nella partita che stiamo facendo con Rail in ASGS, è successa una
cosa strana.
 >> Glauco ha venduto azioni della NYNH tenendosi solo il certificato
della presidenza del 20%.
 >> Al giro successivo c'erano altri giocatori che avevano il 20% e
nel bank pool c'era il 30%.
 >> Il programma stranamente non gli ha permesso di vendere il
certificato della presidenza.
 >> C'è un buco nel programma ?
 >> Ciao.
 >>
 >> Palmiro Matteini
 >> pma...@om...

 Antonio Baracca
 ant...@gm...

Re: [Rails-devel] Update on current branches 1.6.x and 2.0

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

Stefan:
I will merge my future hotfixes both to 1.6.x and master. But I doubt
there will be a lot (or any) of them since we only get bug reports
very seldomly.

--Frederick

[Rails-devel] Update on current branches 1.6.x and 2.0

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

All:
with the release of 1.6.1 I have created the maintenance branch rails1.6.x.

Everyone is invited to merge bug fixes into this branch (in addition to 
the master), however every developer should either merge all fixes or 
none. Otherwise I have not only to look for bug fixes in master, but 
also double-check if it was already merged. So if you are insure, please 
only merge/commit/push to the master branch.

Another update pushed for Rails 2.0: only 18 errors to go ;-)

After some simplification I feel pretty confident that the structure of 
the State and Model classes has reached a stable version. I will come up 
with more information/documentation about those in the near future.

Main current target of refactoring is the mechanism how Items are owned 
by other Items (so e.g. a Player owning Shares, a Tile storing Tokens 
etc, a Corporation owning SpecialProperties): I had to add too many 
variants of Owner classes and interfaces for my taste and will try to 
simplify that further.

Stefan

[Rails-devel] Fwd: 1830 RSM

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

Erik:
I forward you a report of a potentially critical bug: It does not allow 
selling the director of the NYNH given that the operating director owns 
the president share only and 2 other players have 20% each and Pool 
having 30% only.

This bug can be reproduced back to 1.5.3, unfortunately the save file is 
not fully loadable under 1.5.2.

I suspect this is related to the changes for 1835 at that time, I have 
to admit that I cannot fully understand the code used to create the 
actions for selling, so you might be in a better position to find this bug.

Thanks,
Stefan


-------- Original Message --------
Subject: Fwd: 1830 RSM
Date: Tue, 31 Jan 2012 09:30:48 -0500
From: Bob Probst <bob...@gm...>
To: stefan.frey <ste...@we...>

Stefan, a friend of mine found this issue.  I haven't confirmed it yet
but he's pretty thorough.

I'm sure you can contact him directly if you have any questions


---------- Forwarded message ----------
From: "Ing. Antonio Baracca" <ant...@gm...>
Date: Tue, 31 Jan 2012 14:53:37 +0100
Subject: Fwd: 1830 RSM
To: Bob Probst <bob...@gm...>
Cc: Palmiro Matteini <pma...@om...>

Hi Bob,
we have found a major bug on the 1830 module.
The current player cannot sell 10% of NYNH from his president
certificate (remaining so with only 10% of NYNH and shifting the
presidency of the corporation).
I attach a saved file of the current 1830 game with the bug point.
I have seen you are currently in contact with programmers.
Can you please report to them this bug?
Thank you in advance.
Regards
Antonio



Inizio messaggio inoltrato:

> Da: "Palmiro Matteini" <pma...@om...>
> Data: 31 gennaio 2012 14.23.26 GMT+01.00
> A: "Ing. Antonio Baracca" <ant...@gm...>
> Oggetto: Re: 1830 RSM
>
> Eccolo.
> Ciao.
>
> Palmiro Matteini
> pma...@om...
> ----- Original Message -----
> From: Ing. Antonio Baracca
> To: Palmiro Matteini
> Sent: Tuesday, January 31, 2012 11:46 AM
> Subject: Re: 1830 RSM
>
> Mandami la salvata che ci guardo
>
>
> Antonio Baracca
> ant...@ti...
>
> Il giorno 31/gen/2012, alle ore 09:28, "Palmiro Matteini" <pma...@om...> ha scritto:
>
>> Ciao Antonio.
>> Nella partita che stiamo facendo con Rail in ASGS, è successa una cosa strana.
>> Glauco ha venduto azioni della NYNH tenendosi solo il certificato della presidenza del 20%.
>> Al giro successivo c'erano altri giocatori che avevano il 20% e nel bank pool c'era il 30%.
>> Il programma stranamente non gli ha permesso di vendere il certificato della presidenza.
>> C'è un buco nel programma ?
>> Ciao.
>>
>> Palmiro Matteini
>> pma...@om...

Antonio Baracca
ant...@gm...

[Rails-devel] Release Rails 1.6.1 available

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

A maintenance release for the 1.6.x branch.

An update is strongly recommended especially for new games, as otherwise
the game options can be wrong (see below).

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

Thanks to all contributors:
Frederick Weld, Erik Vos

and to those who reported Bugs:
Bill Probst.

List of bugs fixed and further changes:
- Enforced that the DynamicReportWindow stays on top during time warp
- Added background map for 1889 (courtesy of Frederick Weld)
- Fixed autosave functionality (handling of 18xx_autosave.xxx files)
- Fixed retrieval of default game options (if options pane was not opened)
- Fixed 1856 background map's mini-map (Windsor area)
- Enforce selling over-limit shares first
- Fixed wrong price of 6 train (630 => 600) in 18TN

Note: To show a background map, the option has to be switched on in 
Configuration => Map/Report => Display background map.
Background maps are only available for 1856, 1889, 18EU, 18GA (incl. 
Cotton Port) and 18AL so far.

[Rails-devel] Nonmodal dialogs

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

By mistake I pulled the new master updates into my nonmodal branch, which (I
think) forced me to rebase master with nonmodal and push my nonmodal
commits.
(I had rather preferred to keep nonmodal separate for a while longer.  The
work isn't finished, but everything there works fine AFAIK, so no harm
should be done).

Erik.

Re: [Rails-devel] 1880 Implementation: Opinions wanted

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

OK, so using the borrowed train is covered, and Martin could try to copy the
CGR functionality. 

Displaying that borrowed train (e.g. like '[D]') is a different matter, and
if anyone thinks it's important I'm willing to have a look into that issue.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Sunday, January 29, 2012 7:20 PM
> To: rai...@li...
> Subject: Re: [Rails-devel] 1880 Implementation: Opinions wanted
> 
> Martin & Erik:
> I will only comment on the second item:
> 
> The train lending feature of 1856 is implemented by having the
> PublicCompany_CGR extending a StaticRevenueModifier.
> Most likely a similar solution should work for 1880 as well.
> 
> Stefan
> 
> More details:
> 
> This interface requires only one method to implement, see below the
> implementation for 1856.
> 
>      public boolean modifyCalculator(RevenueAdapter revenueAdapter) {
>          // check if the running company is the cgr
>          if (revenueAdapter.getCompany() != this) return false;
> 
>          // add the diesel train
>          if (runsWithBorrowedTrain()) {
>              revenueAdapter.addTrainByString("D");
>              return true;
>          }
>          return false;
>      }
> 
> Some remarks:
> 
> * Static modifiers is called for all companies (so the modifier has to
check if it
> the running company is actually the CGR).
> 
> * The train used for revenue calculation is actually a "virtual" train,
which is
> only created for the use of revenue calculation.
> 
> 
> 
> 
> 
> > b)
> >
> > I believe this is the same situation as we have with 1856 if the CGR has
> > no train: it "borrows" the train that currently is on top of the IPO
> > stack.  Effectively, it runs that train without ever getting it.  I
> > think the same solution should apply to 1880.  So we don't need a new
> > portfolio: it already exists, and is called "IPO".
> >
> > As for displaying a borrowed train: if that doesn't already happen in
> > 1856, it's probably a good idea to add it there too, so it would be a
> > generic feature.  I would start checking out if updating TrainsModel
> > could cover such a case, e.g. by adding a method 'useBorrowedTrain
> > (Portfolio ipo)'.  Passing a reference to IPO would cause displaying the
> > first available IPO train in square brackets (for instance).  Passing
> > null would switch that off and return to the normal display.
> >
> > Erik.
> >
> > *From:*Dr....@t-... [mailto:Dr.Martin.Brumm@t-
> online.de]
> > *Sent:* Sunday, January 29, 2012 12:22 AM
> > *To:* Rails Development
> > *Subject:* [Rails-devel] 1880 Implementation: Opinions wanted
> >
> > Hi,
> >
> > i would like to get some opinions for two todos next on my list.
> >
> > a) Major Companies in 1880 have their tile laying rights bound to a
> > "building" right. This will be determined not at creation of that
> > company but at Start based on the director share type and the player
> > chosing from a number of indefinetely available rights.
> >
> > In Connect with that "semi-static" Right, the company in question will
> > receive a numer of rights if the director of that company holds a
> > private (Taiwan, Ferry, Bridge). Its not linked to the company but
> > through the player to all companies he owns.
> >
> > If i want to display those right i think i'll have to make use of the
> > not yet fully implemented RightsModel Class. Any objections, different
> > approach suggestions here ?
> >
> > b) the train lending feature: For the Investors/Minor Companies the
> > currently in the bank available train is used to determine the Revenue.
> >
> > I would like to have that displayed in the companies portfolio and of
> > course used in the revenue calculation.
> >
> > I propose to generate a 4th heap/portfolio which will hold the not yet
> > leased/lent trains and then use a leaseTrain method that will move those
> > trains into the Minors portfolio upon start/event and move the already
> > listed trains to the scrap heap.
> >
> > Any ideas there ? Cause the low level approch of using the Portfolio
> > mechanismn directly is not what should be done or? (Besides we dont have
> > a removeTrain method thats visible outside of Portfolio for a reason
> > anyway.)
> >
> > Regards,
> >
> > Martin
> >
> >
> >
> >
----------------------------------------------------------------------------
--
> > 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
> 
> 
>
----------------------------------------------------------------------------
--
> 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] 1880 Implementation: Opinions wanted

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

Martin & Erik:
I will only comment on the second item:

The train lending feature of 1856 is implemented by having
the PublicCompany_CGR extending a StaticRevenueModifier.
Most likely a similar solution should work for 1880 as well.

Stefan

More details:

This interface requires only one method to implement, see below the 
implementation for 1856.

     public boolean modifyCalculator(RevenueAdapter revenueAdapter) {
         // check if the running company is the cgr
         if (revenueAdapter.getCompany() != this) return false;

         // add the diesel train
         if (runsWithBorrowedTrain()) {
             revenueAdapter.addTrainByString("D");
             return true;
         }
         return false;
     }

Some remarks:

* Static modifiers is called for all companies (so the modifier has to 
check if it the running company is actually the CGR).

* The train used for revenue calculation is actually a "virtual" train, 
which is only created for the use of revenue calculation.





> b)
>
> I believe this is the same situation as we have with 1856 if the CGR has
> no train: it “borrows” the train that currently is on top of the IPO
> stack.  Effectively, it runs that train without ever getting it.  I
> think the same solution should apply to 1880.  So we don’t need a new
> portfolio: it already exists, and is called “IPO”.
>
> As for displaying a borrowed train: if that doesn’t already happen in
> 1856, it’s probably a good idea to add it there too, so it would be a
> generic feature.  I would start checking out if updating TrainsModel
> could cover such a case, e.g. by adding a method ‘useBorrowedTrain
> (Portfolio ipo)’.  Passing a reference to IPO would cause displaying the
> first available IPO train in square brackets (for instance).  Passing
> null would switch that off and return to the normal display.
>
> Erik.
>
> *From:*Dr....@t-... [mailto:Dr....@t-...]
> *Sent:* Sunday, January 29, 2012 12:22 AM
> *To:* Rails Development
> *Subject:* [Rails-devel] 1880 Implementation: Opinions wanted
>
> Hi,
>
> i would like to get some opinions for two todos next on my list.
>
> a) Major Companies in 1880 have their tile laying rights bound to a
> "building" right. This will be determined not at creation of that
> company but at Start based on the director share type and the player
> chosing from a number of indefinetely available rights.
>
> In Connect with that "semi-static" Right, the company in question will
> receive a numer of rights if the director of that company holds a
> private (Taiwan, Ferry, Bridge). Its not linked to the company but
> through the player to all companies he owns.
>
> If i want to display those right i think i'll have to make use of the
> not yet fully implemented RightsModel Class. Any objections, different
> approach suggestions here ?
>
> b) the train lending feature: For the Investors/Minor Companies the
> currently in the bank available train is used to determine the Revenue.
>
> I would like to have that displayed in the companies portfolio and of
> course used in the revenue calculation.
>
> I propose to generate a 4th heap/portfolio which will hold the not yet
> leased/lent trains and then use a leaseTrain method that will move those
> trains into the Minors portfolio upon start/event and move the already
> listed trains to the scrap heap.
>
> Any ideas there ? Cause the low level approch of using the Portfolio
> mechanismn directly is not what should be done or? (Besides we dont have
> a removeTrain method thats visible outside of Portfolio for a reason
> anyway.)
>
> Regards,
>
> Martin
>
>
>
> ------------------------------------------------------------------------------
> 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