RomRaider

Typically in an office you would just speak to whoever was responsible, likely next to you, with your lips/throat/voice, in person... I have personal relationships with my contributors, or they don't contribute.


Now absolutely everyone in the world has those privileges. Isn't that nice. Unless you wanted to feel special :-)


The bother came when they went to commit their work and there were conflicts. This allows everyone to commit/share/publish and a network of trust to manage how it ends up together in one place before a release. Your work is published, I assume. No need to bother anyone. It's no bother, I assure you.


Yes it is, however not how you framed it. Grasp it, run with it :-)


No, it was precise and accurate. Comments on github are as worthless as those on facebook. That's all I've done since I spent a couple of days merging the mess that was two SVN repos into one neat and tidy git repo.


Yes, and the outcome of that was simply me being more informed. Nothing pragmatic actually happened.


No I didn't, and I strongly recommend that those commits of value (probably not the first three) are cherry picked from your branch.


I'm feeling brave and inspired today, so I'm going to change my ways and actually do something.

Badly bloated RR repo: "Receiving objects: 100% (20779/20779), 111.07 MiB | 1.10 MiB/s, done."
Extra bloat from your updates: "Receiving objects: 100% (277/277), 5.68 MiB | 1.12 MiB/s, done."

Nit picking: http://stuff.fredcooke.com/LotsOfTraili ... zzardo.png

OK, now I actually did something:

• Split three heavy commits out from 4 light commits
• Squashed two build instruction commits into one and removed trailing whitespace
• Unwrapped commit comments to be more readable in different contexts
• Fast-forwarded your light commits into master post reviewing them
• Rebased your heavy commits onto HEAD and pushed them to a temp branch: installer.tool.updates

By splitting the heavy commits out and putting them on a temp branch I've made sure they're available if required, but not a permanent part of the bloat if not. Apologies if I stepped on your toes, Dale. https://github.com/RomRaider/RomRaider/network

Steve, reset --hard to the latest RR master to proceed :-)


Once again, welcome to git. It only needs to go through him if it's going into the "official" repo, which is no different to any other, except by name.


Commit it to a temp branch for peer review. Branches are free. Everything is a branch. Forget your bad SVN-habits and grow :-)

Fred.

Are you this condescending in person?

There are two people who have permission to commit to the master: You and Dale. The rest are sandboxes. Until something gets to the official repository, it won't be in an official release. For that to happen, either Dale or you must pull the changes over.


More condescension. Uh, thanks?


Then I misunderstood what was happening (or not happening).The "issues" I opened (pull requests show up as issues) got closed. I assumed that closed meant closed, as in completed. My apologies.


The white space? Seriously? You wasted time on that? Perhaps you've got time to discuss "proper" use of braces. (I don't).

The bloat, as you call it, is tools updates at Dale's request. Did you answer my question about whether git is capable of storing only the head revision of files (e.g. binaries, generated files)? I stopped wasting my time in your "Game Plan" thread, although that's where I posed the question. The question is posed again here, and an answer would be quite helpful.


Your manner as a greeter is not the most welcoming.


It was not for that reason that I was considering waiting. I thought he might have something to say about the problem and proposed solution.

As for the branches ... That's another discussion for which I don't have time. At least not here. Since they're such a fundamental part of git, I don't see that it would be a real discussion: more a combination of lecture and derision.

The "official" repository is not different as far as the tool is concerned, but it *is* different. It is where official releases come from.

I have no use for my own version of RomRaider. I've created many revisions in the past, but no longer have a Subaru. To that point, I don't even have use for *any* version of RomRaider. I'm willing to perform some maintenance on a system I wrote, and to fix some defects as I have time. My "free" time I had allocated to give back to this community is drawing to a close. We had a week for relocation of our office. I'm going to get very busy again.



I only used SVN for the RomRaider work when it was hosted by Assembla. Again, you assume more than what was said. This is a recurring theme with you.

[quote="Fearless"]I'm feeling brave and inspired today, so I'm going to change my ways and actually do something.

[...]

[*]Rebased your heavy commits onto HEAD and pushed them to a temp branch: installer.tool.updates

[...]

Steve, reset --hard to the latest RR master to proceed

The fix for issue #20 was not part of the tools and installer updates. It's a separate defect fix.

I don't have time for the wealth of humour in that post, so I'll pick out the key bits.


No apologies required, however I should apologise for pointing this out, or it might get labeled as some weird form of abuse: It was you that closed it :-)


There's no such thing as "only HEAD revision", unless you're talking about a filesystem :-)

<snip of a lot of funny things>


I know, it's included. It was one of the light ones.

Fred.

So it says. Perhaps it was after I installed a new JRE for testing. It resulted in numerous duplicate messages in conjunction with "Java wants to do something" message boxes. I did not deliberately do so.


There's no such thing as "only HEAD revision", unless you're talking about a filesystem [/quote]
The question was serious. Are you attempting to be humorous or deliberately being obtuse? I'll pose the question differently. Is there a way to *not* store the revision history, and to only store the most recent version of a file?


I know, it's included. It was one of the light ones.[/quote]

Light, but separate from any tools updates. It doesn't belong in a branch created for tools updates. Oh well.

I noticed the duplicate emails/messages, and wondered what happened. I figured something weird had gone down with the website or your browser :-)


Neither. I was deadly serious. In the context of revision control, it is illogical and a contradiction in terms to have a file that is not actually at any revision, but is just arbitrary.


That's what file systems are for, try EXT4, NTFS or Reiser.

The solution to this, and I know you'll love it, is to not store them there at all, and to use Maven. The other part of that solution will likely be git filter-branch to put the repo on a diet once the fat is no longer required.


What part of "I know, it's included" did you not understand. It's not on the branch. It's in master. Unless I screwed up and am unaware of it. <checks>


No, I made no such mistake.

Fred.

It was the browser. The new Java JRE I installed to test my fixes was being rather aggessive and overbearing.



Your "pound of cure" is obviously trumping my "ounce of prevention."

I'll try one more time. Picture this use case:

Numerous source files for documentation for which the only *generally* usable form is a PDF. The source files require proprietary, expensive tools to produce the PDF. The PDF is binary, and typically not handled well in a version control system. The desire is to replace that generated PDF from time to time, but it does not need to be revisioned *itself* as the source is.

Can git handle this scenario? I know of at lest one SCM system that can, by design.


Then you misrepresented what you deigned to do:



You say you commitetd them to a temp branch. What did you do, if not what you said?

I did exactly what I said. You not understanding it doesn't make it wrong.

I see some commentary in this thread that is less than productive. I wish it to stop please.

Apologies to you and the rest for anything I said that was uncalled for or rancorous in tone.

You can delete the whole topic. I've gleaned what I need.

Just chill guys. I have a bit of a questions with the 64bit conversion. Will the 64bit and 32bit versions behave the same? The only program I have experience with using both version is solid works, I know there are serious differences, 64 bit is faster but crashes more often. And the 32bit and 64bit versions create different FEA and flow simulation results, even if they are run on the same computer.

It's java, so if it works at all, and isn't extremely poorly coded, yes, it'll be the same. The app you're referring to is likely C/C++ which means that pointer misuse/carelessness can mean crashes and so on. The result differences could simply be down to careless use of types, or even on purpose giving more precision in the 64 bit case. It takes some care to produce a portable program that doesn't change across compilers, and few do it right. This may have been OT, but I hope it helps all the same :-) PS, I was chilled the entire time.

This example use case is the same as mine (Log on a crappy netbook, edit on a comfortable desktop). Why can't the features that depend on 32-bit JVM just be disabled (greyed out with a "requires 32-bit JVM" note next to it? Exiting with a message detailing the reason is better than no message but why even exit?

The way it's been implemented (provisionally) is to allow the Editor, but warn that some functions may not work, but to exit with an error if the Logger is started. The message is clear in both cases, although not overly verbose.

The use case that is more troublesome is if someone is now using the logger under 64-bit through some kind of workaround (MacOS X, maybe?). That use case will be blocked with the current, but not yet released, code. I've been discussing this with Dale, and we want to consider this more before settling on a "final" plan.

Right now:

1) Start Editor. Get warning. Launch Logger from menu. Get error. Logger doesn't launch but Editor stays open.
2) Start Logger directly. Get error. Logger exits.

Does the logger itself require it, or just some plugins? If the plugins are at fault, why not blacklist the 32bit/bin ones and allow the rest? JNA which Dale is using works fine on 64 bit linux and osx, at least, and I assume win too.

Did you try to launch the 3d view? It'll likely cause the editor to bail. I'd be surprised if not. If I'm right, it needs protection too.

Fred.