GIT Source Code Repository

[jallum]

I took the liberty of setting up a git repository for OpenCPN. I've imported all revisions of the project from CVS, with full commit comments and history.

Why would I do this, you ask? The reasons are several:

- It's extremely fast... cloning (git parlance for "cvs co") takes about 12 seconds. It's easier to get new developers on board if a checkout doesn't take twenty minutes.

- It's modern... designed from the ground-up to support large scale development on open source projects like the Linux kernel.

- It's distributed... Every clone of the repository contains every revision, ever. No need to involve the revision control server when switching branches.

- It's easy to track upstream changes from CVS... Revisions committed to CVS can be pulled into git, and I'll be doing so periodically until CVS is no longer used.

- It's efficient... Git uses a miserly over the wire protocol, compression and compact binary diffs.

- Branching is extremely cheap.

- Excellent handling of deletes/renames/moves.

As I'd mentioned, I've setup a central repository. It lives on GitHub, and is fully browsable from here: OpenCPN at GitHub

The account costs nothing, and I'll gladly turn over "the keys" to OpenCPN's maintainer upon request.

Right now there are two branches. "cvs" tracks changes from CVS and will contain no new development. "master" contains new work that I (and hopefully others) have done and will be periodically merged with "cvs" to pull in upstream changes.

Pulling the repository is easy. Simply install git (apt-get git-core, yum install git, Git for OSX, etc.) and do a clone:

git clone git://github.com/OpenCPN/OpenCPN.git

I've also taken the liberty of updating and cleaning up the Xcode project for OSX. It's setup for the latest Xcode 3.2.2 (build 1642.0), free from Apple, and will now automatically pull and build the required version of wxMac (2.8.10) as a subproject. Builds for the mac now execute cleanly, and will produce universal binaries -- both PPC and i386 in the same app. These modifications live on the "master" branch in git, which is the default.

Give it a whirl. You'll like it. If you don't, no need to flame... just don't use it.

[cagney]

Thank you Jallum for your initiative.
Yes, git is the future. These things, CVS or Git, has never been discussed, and the need for a discussion has been minimal as long as Dave was more or less alone in developing OpenCPN. This is bound to change, with all the new talented contributors that has popped up the last few months. We will have to see where this leads........

I've also taken the liberty of updating and cleaning up the Xcode project for OSX. It's setup for the latest Xcode 3.2.2 (build 1642.0), free from Apple, and will now automatically pull and build the required version of wxMac (2.8.10) as a subproject. Builds for the mac now execute cleanly, and will produce universal binaries -- both PPC and i386 in the same app. These modifications live on the "master" branch in git, which is the default.

If I understand you right, you must be able to contribute a binary release of 1.3.6 for Mac ???

PM me and I'll put a link to it on OpenCPN.org, I'm sure Psyches would do the same on Sourceforge.

Thomas

[Psyches]

Originally Posted by cagney

Thank you Jallum for your initiative.
Yes, git is the future. These things, CVS or Git, has never been discussed, and the need for a discussion has been minimal as long as Dave was more or less alone in developing OpenCPN. This is bound to change, with all the new talented contributors that has popped up the last few months. We will have to see where this leads........

If I understand you right, you must be able to contribute a binary release of 1.3.6 for Mac ???

PM me and I'll put a link to it on OpenCPN.org, I'm sure Psyches would do the same on Sourceforge.

Thomas

Agreed - thanks Jallum for setting this up. I'd welcome a switch to git, but we will need to have a discussion with Dave. Until then, I'll continue checking in changes to cvs as the master repository, so hopefully the git sync is not too much trouble.

Also I'll try to identify and check in the git changes for OpenCPN/Mac to cvs, within a few days.

Mark

[jallum]

Originally Posted by Psyches

Agreed - thanks Jallum for setting this up. I'd welcome a switch to git, but we will need to have a discussion with Dave. Until then, I'll continue checking in changes to cvs as the master repository, so hopefully the git sync is not too much trouble.

No problem. It's ridiculously simple to one-way-sync git with upstream changes from CVS.

Also I'll try to identify and check in the git changes for OpenCPN/Mac to cvs, within a few days.

Oh, that's easy. Just do a clone from git, and then do a "git diff master origin/cvs > some-name.patch" -- that'll give you a diff of what I've done relative to the latest commit in CVS. you can just apply that patch to your CVS repo and commit. It'll take two minutes.

[Psyches]

Originally Posted by jallum

Oh, that's easy. Just do a clone from git, and then do a "git diff master origin/cvs > some-name.patch" -- that'll give you a diff of what I've done relative to the latest commit in CVS. you can just apply that patch to your CVS repo and commit. It'll take two minutes.

Thanks Jason - clearly it's time to update my git knowledge; it's been on my list for awhile. It looks like the proper git diff needs those branches switched though, right?

git diff origin/cvs master > some-name.patch

Then I have a few quick questions/observations re: the result:

- some .gitignore files are already in cvs (richard.*); I should delete these from cvs, yes?

- there is a wxMac-2.8.10.patch file at the root, with no instructions to apply it in the README or buildosx/README.rtf; so (a) must this patch be applied to wx for the Mac build, and (b) if so, a line in the README is appropriate and it should go into buildosx, or if not, I'll skip the commit of this into CVS master.

...other than the .gitignore, the wxMac .patch, the README, and the project.pbxproj, there are no other changes for OpenCPN/Mac. Just to confirm. For example, I see two .a binary differences in Mac libs, but those don't make it through the patch process - an issue or no?

Thanks,

Mark

[jallum]

Originally Posted by Psyches

Thanks Jason - clearly it's time to update my git knowledge; it's been on my list for awhile. It looks like the proper git diff needs those branches switched though, right?

git diff origin/cvs master > some-name.patch

My bad. Too much typing and not enough thinking. If you have any questions or want to shorten your learning curve, PM me and I'll send you my contact info.

Then I have a few quick questions/observations re: the result:

- some .gitignore files are already in cvs (richard.*); I should delete these from cvs, yes?

I would. ".gitignore" is extremely useful for keeping cruft out of revision control -- you know, binary build products, person-specific config files, etc. CVS has a "cvsignore" facility that is much the same and could be used to the same effect. The exclusions I have in there so far are the bare minimum necessary to keep the repository clean of Xcode's build-system detritus. Additional entries can (and should) be added to keep autoconf/automake's cruft out as well.

Along these lines, I can't help but notice that the repository is littered with code that's not compiled or linked into any incarnation of the app. It would probably be a good idea to take a census of what's needed for each platform, organize those that are platform-specific and delete the files that aren't used on any.

- there is a wxMac-2.8.10.patch file at the root, with no instructions to apply it in the README or buildosx/README.rtf; so (a) must this patch be applied to wx for the Mac build, and (b) if so, a line in the README is appropriate and it should go into buildosx, or if not, I'll skip the commit of this into CVS master.

That patch simply removes two broken compiler settings from PowerPC target in the wxMac Xcode project, and is automatically applied when building OpenCPN using Xcode -- no user intervention required.

This change is necessary for building universal binaries of OpenCPN using Xcode -- something that cannot be easily accomplished using autoconf/automake.

...other than the .gitignore, the wxMac .patch, the README, and the project.pbxproj, there are no other changes for OpenCPN/Mac. Just to confirm.

Correct. My changes so far have been limited to simplifying and streamlining the build process for the Mac, my platform of choice.

For example, I see two .a binary differences in Mac libs, but those don't make it through the patch process - an issue or no?

Those static versions of libiconv and libz are available natively on the mac as dylibs, and should be deleted from revision control in favor of linking against the system-built versions. I adjusted the linker settings on the Xcode project accordingly, and the autoconf/make process can be similarly adjusted. In general, adding build products to revision control is a Bad Idea™ -- if nothing else, knowledge of how to build them is not preserved.

[Psyches]

Originally Posted by jallum

My bad. Too much typing and not enough thinking. If you have any questions or want to shorten your learning curve, PM me and I'll send you my contact info.

Cool, NP. Git seems straightforward enough. It's only the eighth or ninth source mgmt system I've used :-)

I would. ".gitignore" is extremely useful for keeping cruft out of revision control

K, I will delete the ignorables then. Yeah, I'm familiar with .*ignore stuff. Agreed, .cvsignore would make sense too.

Along these lines, I can't help but notice that the repository is littered with code that's not compiled or linked into any incarnation of the app. It would probably be a good idea to take a census of what's needed for each platform, organize those that are platform-specific and delete the files that aren't used on any.

Completely agree and this has come up repeatedly in the last few months - including from me. But I'll wait for Dave first, rather than go deleting lots of stuff while he's away.

That patch simply removes two broken compiler settings from PowerPC target in the wxMac Xcode project, and is automatically applied when building OpenCPN using Xcode -- no user intervention required.

This change is necessary for building universal binaries of OpenCPN using Xcode -- something that cannot be easily accomplished using autoconf/automake.

Got it. I assume it's ok that the .patch moves into the buildosx folder too, to keep separate systems separate. Something we should do with win and linux too, I think.

Those static versions of libiconv and libz are available natively on the mac as dylibs, and should be deleted from revision control in favor of linking against the system-built versions. I adjusted the linker settings on the Xcode project accordingly, and the autoconf/make process can be similarly adjusted. In general, adding build products to revision control is a Bad Idea™ -- if nothing else, knowledge of how to build them is not preserved.

Great, I'll remove the *.a libs too then; completely agree w/keeping build targets out of the version store.

Thanks,

Mark

[Psyches]

Ok, all checked in on CVS master.

[jallum]

The git repository has been brought into sync. One minor difference noted: You put the wxMac patch in buildosx/ and not buildosx/patches/ -- no problem there, as I updated the xcode project to use the new location. You'll want to grab that change and push it into CVS so that anyone building from it won't have any problems.

[Psyches]

Originally Posted by jallum

The git repository has been brought into sync. One minor difference noted: You put the wxMac patch in buildosx/ and not buildosx/patches/ -- no problem there, as I updated the xcode project to use the new location. You'll want to grab that change and push it into CVS so that anyone building from it won't have any problems.

Thanks Jason - it's done.

Hmmm, the original patch back to cvs left the wxMac*.patch in root (opencpn), which is why I posted about moving it under buildosx. I see now that you had placed it below originally...so either the git diff or the patch tool on win32 was a bit broken. Also, the funky win32 gitgui keeps crashing on me when I try to pull - guess not all the tools are quite prime-time ready...but now I think we're good to go.

Mark

[jallum]

Originally Posted by Psyches

Also, the funky win32 gitgui keeps crashing on me when I try to pull - guess not all the tools are quite prime-time ready...but now I think we're good to go.

The git-gui tools blow on all platforms... I've just given up on them and work on the command line. There's probably five or six commands you'll use on a daily basis. All of the cooler features of git are only available through the command-line, so far as I'm aware. (Rebasing, bisection, cherry-picking, three-way merges, etc.)

[balp]

I forked th github stuff. The XCode project didn't work for me, you building on leopard? All frameworks paths was not matching anything in Snow Leopard. There was also a bunch of typecast errors. From newer gcc being harder. All of the was wxT() adding for wxStrings.

My solutions to the build problem was to make teh xcode project form cmake. The bulndle stuff i ahve not made enought tests on. I have a crash when exiting. I have not yet investigated.

I have updated the cmake files to make deb files for debian/ubuntu.

[mzed]

I'm also having trouble building this in Snow Leopard. XCode 3.2.1 doesn't include the 10.4 SDK. I managed to get it by downloading XCode 2.4 and installing it from there.

However, wxWidgets fails to compile with errors starting with "stdarg.h: No such file or directory" It misses some big includes. ?

[cagney]

mzed & balp

Does the Mac binary test release for 1.3.6 on this
page work for you? It's compiled with the code from github.
I'm not on mac, but would like to see a working mac release.

Thomas

[mzed]

Seems to work fine.