Cruisers Forum
 


Join CruisersForum Today

Reply
 
Thread Tools Rate Thread Display Modes
Old 23-02-2010, 04:04   #1
Registered User

Join Date: Jan 2010
Boat: Swan 57
Posts: 59
GIT Source Code Repository

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.
__________________

__________________
jallum is offline   Reply With Quote
Old 23-02-2010, 04:33   #2
Registered User

Join Date: Dec 2005
Location: WNA
Boat: Dufour 35
Posts: 3,247
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........

Quote:
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
__________________

__________________
cagney is offline   Reply With Quote
Old 23-02-2010, 13:05   #3
Registered User
 
Psyches's Avatar

Join Date: Apr 2008
Location: SF Bay Area
Boat: Tartan 30 - Bluegrass
Posts: 187
Send a message via Yahoo to Psyches Send a message via Skype™ to Psyches
Quote:
Originally Posted by cagney View Post
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
__________________
Psyches is offline   Reply With Quote
Old 23-02-2010, 13:15   #4
Registered User

Join Date: Jan 2010
Boat: Swan 57
Posts: 59
Quote:
Originally Posted by Psyches View Post
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.

Quote:
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.
__________________
jallum is offline   Reply With Quote
Old 25-02-2010, 15:49   #5
Registered User
 
Psyches's Avatar

Join Date: Apr 2008
Location: SF Bay Area
Boat: Tartan 30 - Bluegrass
Posts: 187
Send a message via Yahoo to Psyches Send a message via Skype™ to Psyches
Quote:
Originally Posted by jallum View Post
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?

Code:
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
__________________
Psyches is offline   Reply With Quote
Old 25-02-2010, 18:11   #6
Registered User

Join Date: Jan 2010
Boat: Swan 57
Posts: 59
Quote:
Originally Posted by Psyches View Post
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?

Code:
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.

Quote:
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.

Quote:
- 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.

Quote:
...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.

Quote:
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.
__________________
jallum is offline   Reply With Quote
Old 25-02-2010, 18:54   #7
Registered User
 
Psyches's Avatar

Join Date: Apr 2008
Location: SF Bay Area
Boat: Tartan 30 - Bluegrass
Posts: 187
Send a message via Yahoo to Psyches Send a message via Skype™ to Psyches
Quote:
Originally Posted by jallum View Post
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 :-)

Quote:
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.

Quote:
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.

Quote:
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.

Quote:
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 is offline   Reply With Quote
Old 26-02-2010, 16:36   #8
Registered User
 
Psyches's Avatar

Join Date: Apr 2008
Location: SF Bay Area
Boat: Tartan 30 - Bluegrass
Posts: 187
Send a message via Yahoo to Psyches Send a message via Skype™ to Psyches
Ok, all checked in on CVS master.
__________________
Psyches is offline   Reply With Quote
Old 26-02-2010, 16:54   #9
Registered User

Join Date: Jan 2010
Boat: Swan 57
Posts: 59
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.
__________________
jallum is offline   Reply With Quote
Old 26-02-2010, 18:11   #10
Registered User
 
Psyches's Avatar

Join Date: Apr 2008
Location: SF Bay Area
Boat: Tartan 30 - Bluegrass
Posts: 187
Send a message via Yahoo to Psyches Send a message via Skype™ to Psyches
Quote:
Originally Posted by jallum View Post
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
__________________
Psyches is offline   Reply With Quote
Old 26-02-2010, 18:27   #11
Registered User

Join Date: Jan 2010
Boat: Swan 57
Posts: 59
Quote:
Originally Posted by Psyches View Post
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.)
__________________
jallum is offline   Reply With Quote
Old 27-03-2010, 10:29   #12
Registered User

Join Date: Mar 2010
Location: Göteborg, Sweden
Boat: Seamaster 700
Posts: 96
Send a message via Skype™ to 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.
__________________
balp is offline   Reply With Quote
Old 27-03-2010, 14:35   #13
Registered User

Join Date: Mar 2010
Posts: 2
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. ?
__________________
mzed is offline   Reply With Quote
Old 27-03-2010, 14:49   #14
Registered User

Join Date: Dec 2005
Location: WNA
Boat: Dufour 35
Posts: 3,247
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
__________________
cagney is offline   Reply With Quote
Old 27-03-2010, 15:28   #15
Registered User

Join Date: Mar 2010
Posts: 2
Seems to work fine.
__________________

__________________
mzed is offline   Reply With Quote
Reply

Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Code Zero ? bluewater General Sailing Forum 42 12-02-2012 09:50
Dress Code chucktro Monohull Sailboats 34 21-12-2009 11:29
Code Zero Furler kiapa Deck hardware: Rigging, Sails & Hoisting 13 27-10-2009 18:38
No More Code ? GordMay Marine Electronics 3 24-08-2005 05:07



Copyright 2002- Social Knowledge, LLC All Rights Reserved.

All times are GMT -7. The time now is 10:59.


Google+
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Social Knowledge Networks
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.

ShowCase vBulletin Plugins by Drive Thru Online, Inc.