Moving on with deployment and build handling

Development
1

I would very much like to get these things done, and we are very close to achieving them, there’s just a little bit of work left, and they are all interconnected:

a) deploy the Vassal jar and also the source-jar and javadoc-jar as their own maven artifacts, there are several options where we could deploy it, we could even deploy them right there in the github repo and this would be enough for others (module designers) to use them as a dependency their pom.xml.
b) start using the maven clir plugin to test for API compatibility changes, for this we would need something to compare to, and the jar from a) would be the baseline. once this is established we would never again have to manually search for API compatibility changes in every PR, this would free up time for more important matters including all these Vassal NG plans
c) create a template maven project for module designers, this would also need a)

Right now all of this depends on a single step–making the jar it’s own build artifact, and there is a PR that does just that: github.com/vassalengine/vassal/pull/57

It is a somewhat bigger change, not as big as the switch to maven but it could still mean that development environments need to be setup again. I keep this PR merge-able as almost every commit to master introduces conflicts, but it’s somewhat tedious and since I don’t know when/if this will be accepted at all I am not sure whether it’s worth the trouble updating it every day.

2

Thus spake Flint1b:

I would very much like to get these things done, and we are very close
to achieving them, there’s just a little bit of work left, and they are
all interconnected:

a) deploy the Vassal jar and also the source-jar and javadoc-jar as
their own maven artifacts, there are several options where we could
deploy it, we could even deploy them right there in the github repo and
this would be enough for others (module designers) to use them as a
dependency their pom.xml.

This would be a helpful thing for VASL, as they’re using Maven, but
not using it for VASSAL and it’s dependencies, so they have somewhat
of a mess because of it.

Right now all of this depends on a single step–making the jar it’s own
build artifact, and there is a PR that does just that:
github.com/vassalengine/vassal/pull/57[1]

It is a somewhat bigger change, not as big as the switch to maven but it
could still mean that development environments need to be setup again. I
keep this PR merge-able as almost every commit to master introduces
conflicts, but it’s somewhat tedious and since I don’t know when/if this
will be accepted at all I am not sure whether it’s worth the trouble
updating it every day.

I haven’t made it to trying this PR yet; it’s been in line behind bug fixes.
If you resolve the conflicts, I’ll look at it this evening.

–
J.

3

Just resolved them by rewriting history and force pushing, it is now a couple commits based on current master, should be much cleaner than these constant merges from master.

And yes it can help VASL right away, I have seen how they use maven but copy the Vassal jar and all its dependency jars into their code.

I’ve just yesterday realized we can deploy the jar ourselves inside GitHub, here is one project that does this, look at how easy it is to pull the dependency right from github: github.com/javaterminal/Termina … dependency

We could deploy the released jars inside the main repo, or make a separate github repo for it under the vassalengine organization.

4

Thus spake Flint1b:

Just resolved them by rewriting history and force pushing, it is now a
couple commits based on current master, should be much cleaner than
these constant merges from master.

Merged.

–
J.

5

Lots of conflicts in PRs behind this one now, but I expect they’ll be
mostly trivial to resolve.

J.

6

Even the ones I’d think would be simple say “too complex to resolve in the web thing”.

So I guess I need the lesson in how to resolve them w/o the web thing. (what git commands, in other words)

7

Thus spake Cattlesquat:

Even the ones I’d think would be simple say “too complex to resolve in
the web thing”.

So I guess I need the lesson in how to resolve them w/o the web thing.
(what git commands, in other words)

These won’t be very hard to resolve, as they’re not due to overlapping
edits. (I’m not sure why there are conflicts, to be honest, since these
are just due to moving files around.)

–
J.

8

Right. It just won’t let me resolve them with the normal “resolve conflicts” button which is greyed out “because it’s too complex”. But if I check out the branch for one of them and then type “git mergetool” it says there are no files that need merging. So just confused.

9

Thus spake Cattlesquat:

Even the ones I’d think would be simple say “too complex to resolve in
the web thing”.

So I guess I need the lesson in how to resolve them w/o the web thing.
(what git commands, in other words)

Try resolving conflicts on the selection toggle one first, as that’s
the one I’d like to merge next.

–
J.

10

Yeah that’s the one I started with because I thought it would be “easiest”.

I tried a rebase on master command and now I’m in a world of hurt.

11

Okay it was a total disaster I did “git rebase --abort” and will await professional help :slight_smile:

12

…oooooor maybe I must have typed something wrong the first time. Second time worked as if “duh nothing’s even wrong”.

If it passes its travis check it’s ready to merge.

Any particular priority order for other PR’s to hit and attempt not to destroy? I don’t have a feel for your 3.3.3 plans / target schedule / etc, so I’m just assuming “at some point we’re cramming this all in a beta”

13

Whew, the “crown jewels” are safe – I got HTMLChatter to rebase :smiley:

14

Thus spake Cattlesquat:

…oooooor maybe I must have typed something wrong the first time.
Second time worked as if “duh nothing’s even wrong”.

If it passes its travis check it’s ready to merge.

Any particular priority order for other PR’s to hit and attempt not to
destroy? I don’t have a feel for your 3.3.3 plans / target schedule /
etc, so I’m just assuming “at some point we’re cramming this all in a
beta”

I’m tyring to work though the bug fixes first, though I’m also picking off
ones which are easy to review as I go.

The list of changes over 3.3.2 is getting to be rather long now; keeping
the releases smaller makes user reports of problems more useful, as it
narrows the range of chances which can be involved. So I’d like not to
include too much beyond what’s already open in 3.3.3.

–
J.

15

Thus spake Cattlesquat:

I tried a rebase on master command and now I’m in a world of hurt.

There’s more than one way one can get to a state where a conflicted PR can
be merged. Our experience so far makes me think GitHub doesn’t handle one of
those ways very well.

The two ways:

  1. Rebase your branch onto master.

  2. Merge master into your branch.

Either of those should make your branch mergeable into master. A rebase can
be cleaner sometimes because that can mean the merge of your branch into
master is just a “fast-forward”. (A FF is just a merge where HEAD in the
target is some number of commits behind HEAD in the source, in a straight
line.)

GitHub seems to be including as changes in a PR where you’ve rebased all
the commits which were involved in the rebase—which is totally wrong
and obscures what the actual changes were. The whole point of a rebase
in this case is to apply your changes in one shot directly over master,
so one would expect GH to see that those commits involved in the rebase
are already on master. (BitBucket works like this…)

I just tried updating my Windows LaF PR by merging master into it instead:

github.com/vassalengine/vassal/pull/64

Note that this is showing one file changed—the one file I actually
changed—instead of zillions of files.

So… I’m not sure what’s going on here. I’m going to test a bit, because
the changed files display it has for PR 64 after I merged master into my PR
branch is how it should also look if I’d rebased. Either GitHub is being
stupid or Brian’s doing it wrong—I just don’t know which one yet.

–
J.

16

Okay, for the record the sequence of commands I was normally using was:

git checkout Bugfix13191
git rebase --onto master Bugfix13191
git pull
git push
git push -u origin Bugfix13191

I will fully admit to “only barely understanding” what the three middle commands even do. So if someone provides a different set of steps I’m happy to do it instead.

Meanwhile having apparently erased the entire contents of PR 107, I stuck up PR 110 which has what I had when I finished 107 and built the final successful test the other day (huge bonus dividend of having had to build that on a linux virtual machine). But it will surely have to be remerged in all sorts of painful ways so I’ll wait to see if we can recover PR 107 before attempting it.

17

Thus spake Cattlesquat:

Okay, for the record the sequence of commands I was normally using was:

git checkout Bugfix13191
git rebase --onto master Bugfix13191

AAAAAAAAHHHHHH!!!

You likely have two problems here.

(For anyone reading this who knows how git works: Yes, I know how git
works myself and I know I’m being a bit inexact and hand-wavy here.)

When you rebase, what you’re doing is taking one branch and pasting
another branch onto the end of it, more or less.

So, the syntax is this:

git rebase [–onto ] []

is the branch you are pasting onto, hence the name of the
option. The --onto flag is optional, so if you don’t specify it,
defaults to , and is also optional, defaulting to the
branch you’re on.

When you’re trying to do some particuarly complex history rewriting,
you can have situations where , , and
are three distinct branches, but that’s not the situation you have
when you’re just trying to remove de-conflict a PR.

What you want for fixing a PR is for and to be
the same, and for to be the branch you’re on.

So, the correct command to rebase Bugfix13191 over master when you
have Bugfix13191 checked out already is this:

git rebase master

If, instead, you do

git rebase --onto master Bugfix13191

you’re making master, but you’re making both and
Bugfix13191, and the result is what you’ve been getting, which
is Totally Fucked Up.

I’ll follow up with a bit more in a few minutes…

–
J.

18

The second problem I suspect you are having is this: When you rebase (or merge, or anything except a pull), you’re using your local copies of branches, but GitHub is computing diffs using it’s local copies, not yours. GitHub’s local copies are “remotes” to you. So if you’re going to rebase, it is essential that before you do so, you ensure that the branch you are using as your (and ) are current—if you don’t do that, you’re pasting your changes onto a branch which is behind what GitHub has and inviting a mess.

So, the right way to do the whole process is:

git checkout master
git pull
git checkout Bugfix13191
git rebase master
git push

19

Oooooo. I look forward to serving my overlords with a new set of commands!

I guess that just leaves “dealing with the current mess.”

20

That last push will probably need to be a “force push”, which always makes me feel like a Jedi when I do it:

git push -f

(You’ll get an error when you try to do a regular push after rewriting history, because by doing a rebase you’ve changed the DAG in a way which is incompatible with what the remote had before. The -f just tells it that you really intend to replace the old branch with the new, rewritten branch.)