RomRaider

I'm pretty interested in working with you guys on RR (for my own slightly disparate reasons) but I refuse to allow subversion to be installed on my machines. It has some uses, but not many, in 2012.

If you're up for the change, I'm happy to do the migration to Git for you guys. It's actually pretty easy to do and facilitates much easier collaboration and is much much higher performance in day to day use. The tool is called git-svn and imports the entire project history attaching branches and tags correctly, etc. Because your svn structure is pretty standard it should "just work".

How many active devs are there that would have an opinion on this? Names? I'm happy to get on the phone and have a chat about it if you guys are I'm on Spanish time, though (living in Barcelona for the time being) so finding a good time to call might be less than easy.

Excuse me being a pushy noob! The next thread is going to be equally pushy, too. Sorry in advance

Fred.

You'd need to contact qoncept to coordinate a move.

Is it just you and him working on it, mostly? Is he active on the forum at the moment? Will he see this thread? Should I PM him my contact details? Let me know how to proceed. In my eyes, this would be the first step for me, before touching the code at all.

I don't want to be TOO pushy as a change of tools is always a disruption to core work, but it is a winner and 100% worthwhile I hope you guys agree.

Fred.

I think he pops in once in a while, but a PM may get a quicker response. AFAIK, I'm the only one doing any dev at the moment and any change like this will be another learning curve for me. I honestly don't know what the difference between the two repository styles is.

Currently I'm trying to change from J/Invoke to JNA to be able to support any J2534 PassThru cable and so I can add support for native USB comms through FTDI based cables (i.e.: VAG-COM). This would allow for better cross-platform support of those devices (I'm trying to get away from serial ports).

There's a lot of work to done and I have very limited programming skills and time to send on any of it so changes are slow to come.

OK, well how about I give you a call to a land line from skype and we have a talk and I explain my motivations and git to you, etc?

Let me know if you're keen.

Fred.

PM sent!

Got your PM, and like Dale said, I'm basically just popping in from time to time right now. I've been peaking at the code and making minor changes to the trunk I have checked out but unfortunately I just can't make the time to do anything very useful.

I'm not opposed to moving to git but I definitely want to make sure we don't do anything half baked or lose interest part way, and we obviously want to make sure the current svn repo remains functional until the migration is complete.

We've all been saying for a while that the current build is getting stale and has some major performance issues, and I really think rewriting the GUI rom scratch is the best option at this point. Maybe it would make more sense to start with that rather than dumping in a bunch of source files that will never see the light of day again?

Disclaimer: "That" has been half-way completed attempts by me over the last 4 years.

The only thing that would be nice to do with respect moving to git and losing history would be to subsequently rewrite history to remove the jars such that the repo isn't unnecessarily HUGE as it is right now. Other than doing that, it's very straight forward. As in, correctly cloned in about 30 mins max depending on the svn server speed, including all history. I personally prefer to maintain some history (most of it, or all of it, preferably) even if you're going to do a "big rewrite". I didn't look at your gui code much, but I did look at your gui, and I quite like it.

In terms of migration, it'd be a matter of continuing to use svn until you were comfortable that the migration was a good one, and then just switching it off to not allow more commits, and beginning commits directly in git.

If you really wanted to get fancy, I think it could be possible to lay the current repo history on top of the old repo history and get a full history from the start. Maybe you don't care, though, and that would certainly increase the work involved well beyond "trivial".

If you're both happy to make the move, and you don't want the old repo history, I can get it done and link you to a repo to clone and play with. Thinking again, the jar issue isn't as bad as I thought. Someone cloned your svn root the other day and it was over half a gig, but your tags/branches likely contributed to quadrupling the real numbers or worse.

Just say the word

Fred.

Forgot to say:

I don't like your idea of starting a fresh repo and losing all of your dev history and comments etc. That stuff is valuable information IMO. So consider my vote against that. If you're going to go crazy refactoring/rewriting stuff, do it post migration.

My 2c

Fred.

viewtopic.php?f=14&t=6880&p=78885#p78885

OK, so, your old repo has 797 commits in it, and the new one has 371. If the transition was done cleanly with an exact copy of 797 for 1 of the new repo, then it should be possible to reassemble them using git and some magic.

I'm putting aside every Tuesday for the foreseeable future to develop something tuner related. This weekend can be git and maven, and if I'm not done, I'll spend Monday on it too. Assuming you guys are up for it. Don't worry about committing more stuff while I work. Git will allow me to move my changes on top of yours pretty easily.

I'm going to go ahead and have a crack at it, and if you guys don't like what I do, I might just maintain a git fork of the app with my changes applied to it. You'll likely not want my changes initially anyway, as I'm planning to just hack things in to get them working. I can clean it up later and try to find a smooth way to integrate it.

I'll let you know how I get on and post any relevant links if/when I have some success.

Fred.

I did some work on this yesterday and got some good results and some surprising results. I need to tweak things a bit more and figure out how to proceed with the clone to get the most complete and accurate results.

Straight git clone was 578 meg and standard layout clone was 174 meg. Surprisingly (surprise! ) the new repo had a whole slew of tags from the old repo, but in the current version, they're not there! Bizarre! I assume that I know why that happened, but need to understand it fully and handle it properly.

If I do a good job, a full git clone of both repos should be under 200 meg or so, with a full history. That won't go away when the jars do, though, but isn't unbearable, so rolling with legit full history seems like the best plan right now.

More info as it comes to hand.

Fred.

OK, old cloned with custom args, and it's only 153 meg. A lot of that will overlap the 174meg new one, so I should be close with the 200meg thing IF I can figure out the best approach to merging them. More updates soon, hopefully.

Hey guys, below is the list of committers from both repositories in the combined state. For each one I need a current or future git commit nick or name and a current or future preferred git-use email. Git emails are fairly public. I use my primary email, as do most, however some may wish to avoid doing that.

Details look like this:



I switched my email and surname for the time being, though it'll be obvious soon enough what it is, just not ready to share, yet. Again, using the real thing is the norm. If you don't want to, that's fine, just the commit ownership stats get a bit muddled up. In all cases, though, I need to use _something_ in the author migration file to get a meaningful result. I'd forgotten about this earlier, or I'd have asked then...

This is the combined list:



And for my reference, old repo list:



And for my reference, new repo list:



I'm fully aware that some of these people have been gone for 10 years, however we'll need something for each one, even if it's bogus, or an account we setup on their behalf for them to use later.

For anyone wishing to commit to this thing, please sign up on github.com. The nice thing is that you don't have to, but github is the centre of public git and has a nice set of UI tools for visualisation. It's not like SVN where you have to setup an account as admin for each user. The user sets up their own details, forks/clones the repo, starts making commits, and pushes it to their own public git online account. Then, as control committers of the master repo, you can either take or leave their work depending upon the quality of it, etc. IE, it lowers the barrier of getting work done in a controlled way.

I've setup a github account for the project, and once I'm done moving things around I'll change the email to someone elses and a temp password and hand over control to the right person. Keep in mind, even qoncept and dschultz shouldn't use the project account as their commit account. Who ever controls it can just add them as collaborators and they can push to it as though it was there own. Only one person should usually do that, and I'd guess that gate-keeper job should go to dschultz at the moment, as he seems to be the only one active. Each person should be committing to their own fork, and someone should pull those in and combine them through (usually) automatic merge and/or rebase.

The new repo will need a few minor changes once finalised, such as empty dirs filled with empty .gitignore files to keep them alive (git ignores empty dirs) and a main .gitignore file at the root to keep things neat and tidy. You've likely got a set of existing svn ignores anyway which we can include in that when the time is right.

dschultz, if you have any pending changes, you'll have to make a call about getting them into SVN soonish, or into git after I'm done. I can redo the process that I'm doing pretty easily, so SVN is 100% fine and I don't want to get in the way of your progress. IE, soonish is loosely said

I don't want to start making maven changes until I'm working from the same history as you are, though, so sooner = better for me.

Can we have a chat on skype to clear up the best way through this transition?

Can you also turn off commit access to anyone that doesn't need it, just to be sure to be sure, like the Irishman wearing two condoms.

Fred.

On second thoughts, what we use only matters for those still around, and then, only those who are likely to make further commits in future. And even then, it only matters in terms of commit ownership history, so it's not the end of the world. It'd be nice to do it right, though

I do have some changes to commit, which I can do soon.
What time can we chat? I'm on Eastern time and available after 22:30, or maybe tomorrow 17:30.