OSDev.org

I have several computers like many other, small laptops, larger laptops depending on what trip I'm on, basically several computers. Right now my OS projects and other projects are moved between these computers manually and I have no version control software which means that I copy the entire directory tree every time I want to make a "check point" or "freeze". Not very efficient and I've always said to myself now I'm going to fix this but I always delay this.

So, my question is how you are managing your personal projects and what kind of software and hardware you use. What I want to use is some kind of version control software and it will probably be GIT as it is free and quite easy to use and GIT seems to be quite agnostic regardless if you have it locally or on a server. Also that I have several computers makes it a bit more difficult. I really want to have some central storage where I keep my projects, so that you can easily sync with any computer. I can setup an ftp server but as I move a lot this means it comes with me anyway. I cannot leave something on at all times at home. Are there any public places where I can keep my source code? I've seen GIT hub and such places but does that mean that the source is available for the public at all times or can you control this. My projects aren't really open source projects at this stage.

Any suggestions?

I use a dedicate machine with svn+apache+ssl+dyndns. SVN/post-commit scripts is programmed to make remote backups, etc.
The machine is configured with wake-on-lan to reduce power consumption.

Hi,

Do you have a budget, or does the solution have to be free?

If you use a paid hosting service with git, you can ensure that only you have access to your repo, or can install something like git-php to make it browsable to the public. I have a web page hosted for reasons other than programming, but it happens to come with git over ssh, which is pretty convenient. I use that for all my Windows, Web and OS programming. The disadvantage of my particular host is that I only get one ssh login - not a problem for me because I'm the only one who uses the repo.

If you use a free hosting service, be prepared that you will have to go with their constraints.

As a third alternative, you may not want a PC on at home all the time, but how about a NAS that can do ftp? You may be able to do something with that (although you'd obviously have to check that any NAS you but is up to the job!).

Cheers,
Adam

Doesn't GitHub have private repos? I just got one reason not to switch to it from BitBucket, which I believe to be roughly GitHub =~ s/git/hg/, and has IIRC 5 private repos in the free version.

No, GitHub doesn't have any private repos. Furthermore, you can never take your sources off GitHub.

fronty wrote:Doesn't GitHub have private repos? I just got one reason not to switch to it from BitBucket, which I believe to be roughly GitHub =~ s/git/hg/, and has IIRC 5 private repos in the free version.

BitBucket now has unlimited private repositories and unlimited storage for said repositories. The paid plans decide how many users are allowed to access said repositories.

I'm personally in favor of Mercurial over Git, simply because it has better branch tracking. Git has a culture of "rebase" and other history rewriting tools in order to keep the history "clean", which is mainly needed because Git doesn't record what branch a commit was made against. Hg tags every commit with the branch it was made on, so that when looking at the repository history you get a more clear view of how development was done. Otherwise, they're very similar, however, Hg behaves far better on non Unix platforms, and has the advantage of all being written in one language from a portability perspective.

Love4Boobies wrote:No, GitHub doesn't have any private repos. Furthermore, you can never take your sources off GitHub.

False and false. Github does charge for private repos, but it's free to delete a repository.

My bad. Is this a new service? I didn't notice it before.

They've had it for as long as I've had an account, so it's been around for a year at least.

If you want offsite backup and an easy way to distribute it, GitHub and BitBucket are good though (BitBucket supports Git now).

As the question was about how we are managing our projects... I have a domain registered with a small hoster, who - in addition to the usual mail / webspace service - also offers one-click installations of SVN / GIT repositories, Trac, Bugzilla and a couple other development-type software packages.

All my projects are stored in SVN repositories at that hoster. I keep the working directories on the three to four machines I am working on in sync via "svn update", and in addition the hoster does keep proper tape backups of everything in case of disastrous failure.

As others have pointed out, there are services like that available that are free. But I always preferred to keep stuff like this with a small commercial hoster. Having a payed contract, you are eligible for a certain level of support, and being with a small hoster increases your chances to actually get it. (I've solved certain issues, like migrating from one Trac release to another, with the hoster on the phone. The person running the company, not some call-center button pusher. You don't get that level of support from either free or large-company hosters.)

I run a small forge-like service, called QuokForge. It's available via quokforge.org (domain and some help running the place courtesy of JackScott). I host quite a few projects there, including Pedigree. I run redmine for the forge-software and support primarily svn, git, and hg. Free hosting for projects, both public and private, and I don't monitor disk usage currently as it hasn't been a problem before. However, there's a couple small caveats:

* For private repos, JackScott and I have access to them by virtue of being the admins of the service, so we get access to everything on the server.
* It's run on my home broadband connection, but I've only a very few times had problems with that. The connection speed is pretty quick. I'd go with colo or VPS if I could afford it, but right now I can't.
* Projects must be osdev related.

I also have project creation disabled, so if you want to host a project at QF, you'll have to contact me first. I'm always on Freenode in #quokforge, or you can email me or PM me.

You can delete your repos off of github, and all that, but the search results on their internal search engine remain, so it seems like their indexing records are left behind. I simply emailed the "Tekkub" gentleman and asked him to remove the indexing ghosts and that was it. It can be done :O

I use the Netbeans IDE which is linked into my cygwin install, allowing me to compile and test with a single click. I mostly use Bochs for testing, but I also use VirtualBox and VMWare vSphere to test.

As far as version control goes, I use git. Git is available as a plugin for Netbeans, which gives me line highlighting and all those nice things. I mostly manipulate the repository via the cygwin command line (which I either SSH into or use Netbeans' own shell, both far better than cmd.exe).

Project hosting is via QuokForge, though I also mirror the project on GitHub. In my larger projects (lazy me is yet to implement it for my toy OS) I use a similar branching model to Pedigree and this bloke, which I think works really well for Git.

You should all check out QuokForge. It's awesome. And I'm not biased at all.

JackScott wrote:In my larger projects (lazy me is yet to implement it for my toy OS) I use a similar branching model to Pedigree and this bloke, which I think works really well for Git.

I have two issues with this model:

• By convention, master or tip is the branch on which development occurs (the same as SVN's trunk)
• It assumes a linear sequence of version numbers: 1.0 -> 1.0.1 -> 1.1 -> 1.1.1 -> 1.1.2 -> 2.0 -> ...)

The first one is purely a matter of taste, but the second one is a matter of both practicality and being a good upstream.

• Practicality: "1.1 RC1" is a release, but you may still need to release a "1.0.5" because of an urgent security issue
• Being a good upstream: You make distribution packagers and end users a lot happier if you have a defined release support timeframe - and, if what you are developing is a platform of some sorts - it is downright rude to force someone to choose to either accept something being broken or having a security hole.

Therefore, I prefer a model where

• tip or master is where work for the next version of the software is landed
• releng-X.Y is the branch where release engineering for releases of version X.Y are developed. It branches off around the period at which the software is largely functionality complete, and will later enter a period at which it accepts only bugfixes
• releng-X.Y.Z branches may be made if they are necessary (e.g. if a bug is found affecting the 1.0 branch, but which is not critical enough to land on the 1.0.0 release, a releng-1.0.0 branch would be created so that this fix can be landed without affecting the 1.0.0 release process. When 1.0.0 is released, this branch would be retired
• When a release is made, it is tagged on its respective release engineering branch as "vX.Y.Z"
• When support for a release series ends, its release engineering branch is closed.
• Bug fixes for released versions are developed on branches from the release engineering branch for the earliest supported affected release

Merges always proceed upwards, e.g. releng-1.0.0 -> releng-1.0 -> releng-1.1 -> releng-2.0 -> master