views:

309

answers:

9

Is it insane to integrate Git into the project that has nothing to do with source control.

I am thinking about data collector that regularly runs several commands on the client side and commit the output into the local git repository. If remote server is available it pushes the data in origin for further processing on the server side. In this scenario I will have compression, history and various delivery methods for free. What are the drawbacks?

+1  A: 

"Git is a free & open source, distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Every Git clone is a full-fledged repository with complete history and full revision tracking capabilities, not dependent on network access or a central server. Branching and merging are fast and easy to do.

Git is used for version control of files, much like tools such as Mercurial, Bazaar, Subversion, CVS, Perforce, and Visual SourceSafe. "

Schildmeijer
Haha, you said Perforce!
drozzy
+6  A: 

It's not insane, no. Git was originally designed to just be a version controlled file-system, which would be later used as the basis for a source control system; however, things didn't quite go that way and git became the source control system. That being said, it's still very much a file-system design, and there's no reason you couldn't use it for other purposes (in fact I was going to do something very similar myself, but the project never panned out).

James Gregory
+2  A: 

It depends on what kind of data you want to process. If you're talking about small bits of data, then use a database instead, but if you want to track modifications to documents, then I don't see a problem building your system on top of something like Git.

CookieOfFortune
A: 

no its not just for source control.

people use it as a versioning system for all kinds of documents like manuscripts, speeches, etc...

git doesn't have to be used with software source control, you can use it however you want

cpjolicoeur
+1  A: 

To me, it would seem easier to collect data in a database. In a database, the information is organized, easily accessible, and can be manipulated easily. Also, if you need accessible to people remotely, allow other domains access to the database.

Whereas in Git, you're stuck storing everything into flatfiles. It is your job to then parse all that information, and if you have a lot of information, this can take a long time. However, databases are usually pretty quick about returning the exact information you want.

contagious
The difference is searchability and speed of access. While I love GIT, it's not a DB.
altCognito
It depends on whether the database is set up to handle tracking the history of the system - assuming that is important, as it seems to be for the questionner. Also, synchronizing databases across systems is non-trivial, especially if they are sometimes disconnected.
Jonathan Leffler
@Jonathan I've actually run into the problem of syncing db's. Getting everyone dumps of the same db is a pain, and i'm actually not aware of an auto-sync option.
contagious
+2  A: 

There are already several backup systems available based on Git, for example Gibak. So it's definitely able to handle large datasets efficiently/secure.

A drawback will be, that you won't be able to merge binary data.

David Klein
+1  A: 

Sounds like what you are looking for is a messaging queue or service bus of some kind. There are many of those. Of course, if Git works for you, why not? But just make sure you aren't just using it because it is the only tool like it that you know.

Yishai
+1  A: 

I can't see how this would be a bad idea. Git is great for managing large and small amounts of information. Binary or text are both allowed and kept revision history of.

This could probably work just like iFolder, but with much better ability to merge, keep history and share your information.

One of the problems is the complexity unerlying this kind of setup. Unless your users are well versed in git branching, conflict resolution by merging, and applying patches manually, you will have to make some tough decisions on how to dumb down the system.

The idea of GUID is also going to be confusing to end users, so you might have to build something simple (version numbering) on top of that. The no-empty-folders allowed dilemma is also one you will have to address.

The good thing about git (as opposed to svn or iFolder) is that moving a file is easy, and merges are smart.

Overall, git does good managing our binary image, media and code files all in one repository. I can't think of why it could not be used as a helper for any other kind of project, to keep track of documents, images and other media.

drozzy
+1  A: 

I use Subversion for database backups. One row per record with many static records makes svn a quick and easy backup solution. No meaningful drawbacks that I can see. From one random Internet guy to another: you have my support!

Adam Backstrom