Like gitHub, but better

[parkint]

I am very proud of this idea.
I created a video that explains how to create your own remote git instance, without a server (no web hosting required) for FREE.
No fuss.  You can control access to multiple repositories.  Better than gitHub.  Better than Unfuddle.
Check out the video.

I encourage comments.

EDIT: A more detailed description is located further down in this thread.

[mouser]

This looks really interesting.. going to watch it in full now.. since i haven't used Git i'd really like to hear more from people who do.

I think having a video demonstrating the idea is wonderful, but maybe you could tell us the main ideas in a paragraph or two as well here, just to lay the ground work while we are watching?

[Ehtyar]

Mouse Man, if you're still on Windows exclusively, don't bother unless yuo're willing to use it under a POSIX-like emulation layer (msys or Cygwin atm).

Ehtyar.

[parkint]

The Windows "emulation" (MsysGit) is quite good.  It is used in much of the video.
For anyone who is unfamiliar with git, I would like to say this:

•   git is unlike other CVS (subversion, sourcesafe, etc) and it can be a bit intimidating.
•   In order to use git properly you need to let go of any old habits from SVN or Subversion
•   After using them all, I honestly believe git is better.  The strength comes from the fact that it is primarily 'local' and file-based.  At first that sounds like a limitation, but is really quite an outstanding strength.

I will not try to describe git here because there are numerous resources on the web.  My first recommendation is this great blog entry, followed by ProGit (free book online).

Traditionally, in order to use git with remote access you need nothing more than a Linux server (most free/cheap hosting) with SSH access and an instance of git installed.  There are a few places, like github, where you can store repositories for free as long as they are public.  I had some stuff I wanted to keep to myself - yet needed to collaborate with other developers.
This video demonstrates a method I devised whereby you can HAVE IT ALL and PAY NOTHING.

Thank you for your feedback.

[Ehtyar]

I use msys and Cygwin both on a weekly basis. They're both perfectly usable if all you want is an interactive terminal, but for automated use or scripting they're slow, bloated and a pain in the arse to work around.

You are correct, however, that distributed VCS has some advantages over server-based ones in certain situations, though I wouldn't consider the benefits worth trading in native platform support for. Some distributed VCS with native cross platform support include Bazaar, Mercurial, darcs (though there are no "official" windows binaries), and SVK (based off of Subversion).

Ehtyar.

[f0dder]

One thing I really like about a traditional (usually-)server-based VCS like subversion is that once I commit, I know that I have a "backup" of my source code on the server... and since I work on multiple machines, having some centralized repository (and keeping it up to date!) is vital as well.

I've considered looking into distributed VCS, though - sometimes I need to do work where I don't have access to my centralized repo, and it'd be nice to still be able to do commits. Also, when I eventually open-source fSekrit, I'd really like to keep the repository on my own server, but push changes from there to a public repo (and only allow read-only access to the public repo). I've been recommended SVK in the past (by tinjaw iirc), but never had time (or enough incentive ) to look at it.

Ah well, a general discussion of VCS is probably best suited for another thread.

[parkint]

I don't disagree with you, F0dder.  And every tool should be used for its specific strengths.
For open-source (public, read-only access) projects git seems to be gaining popularity quickly.
In the scenario you described, the ability to distribute "patches" as an email attachment is a handy feature in git.

This is not a general discussion about Version Control systems (is it CVS or VCS or both?)

As my 'entry' to this group, I wanted to make a contribution.  And so, the video is my first showpiece.
Thank you for the warm welcome (and intellectual banter) to this group.

[f0dder]

This is not a general discussion about Version Control systems (is it CVS or VCS or both?)

Sorry for doing a potential topic hi-jack . Anyway, VCS=Version Control Systems (generic term), CVS=Concurrent Versions System (specific (and horrible) product).

I'll see if I can find the time to watch your video a bit later today - and welcome onboard

[ewemoa]

Being unfamiliar w/ Dropbox, I visited Wikipedia and found the following text:

The Dropbox client enables users to drop any file into a designated folder that is then synced to the web and to any other of the user's computers with the Dropbox client. Files in the Dropbox folder may then be shared with other Dropbox users or accessed from the web. Users may also upload files manually through a web browser.

My rough understanding of the idea being presented is (assuming you have git installed locally):

Set Up
Get Dropbox account (on their service) and client installed (on your local machine)
You now have some local folder which gets synced automatically w/ the Dropbox service
Create your git repositories within/under the folder in question (can be shared via the Dropbox service w/ other users)

Use
Use git as usual(?)

Does that sound about right?

[Eóin]

I use git all the time. Mostly I use it in the server-client role in the sense that I'm always push my work to a server through ssh and all the other machines just pull and push from that. But the ability to continue working even if offline is a huge bonus.

Also if anyone has tried to manage branches or merges with say CVS or subversion you'll be in for a treat with git, it's just so intuitive how it works.

Finally anyone using git on Windows, I'd highly recommend using TortoiseGit with it, it's a joy to use.

[parkint]

My rough understanding of the idea being presented is (assuming you have git installed locally):

Set Up
Get Dropbox account (on their service) and client installed (on your local machine)
You now have some local folder which gets synced automatically w/ the Dropbox service
Create your git repositories within/under the folder in question (can be shared via the Dropbox service w/ other users)

Use
Use git as usual(?)

Does that sound about right?

Yes. That is a very good characterization (Reader's Digest Condensed Version) of the video presentation.
Dropbox is a free service.  As you said, your 'local' folders are synchronized with their server.  All data is stored in encrypted form.  You have control over sharing of any folders.  The data is under version control and Dropbox allows you to revert to previous versions - a bit redundant and unnecessary in this particular application.

Because git is file-based, the repository can be stored in one of these Dropbox folders.  As has been mentioned, where you traditionally "push" your updates (commits and branches) to a server - in a client-server relationship - this schema I outlined in the video allows you to utilize the Dropbox in place of a traditional server.

The services available for "server-based" git repositories, like github, cost money (with github you can host for free but it remains public).
The schema presented in the video uses all free facilities.

[ewemoa]

Does that sound about right?

Yes.

Thanks for checking

I haven't thought it through much but it occurs to me that the presented idea might be adaptable to some non-git things too.  For example, perhaps it might work for Mercurial?

[steeladept]

DOH!  Ignore this post.  I meant to post in a different thread.  It was supposed to go to this thread.

[kyrathaba]

I use the free package at http://beanstalkapp.com/, in conjunction with Tortoise SVN, for backing up my C# projects.  Works simply, quickly, and was a breeze to setup.