Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

If you install GIT or SVN (Server Repo) on Linux, will it run any permanent processes i.e. will it leave a permanent memory footprint on my Linux server?

I'm on a server where keeping down memory usage is of the essence.

share|improve this question

migrated from stackoverflow.com Oct 29 '09 at 21:15

This question came from our site for professional and enthusiast programmers.

4  
do you know of any programmer who doesn't use version controls. get a life. – Adergaard Oct 28 '09 at 19:59
4  
@Beska: clever. I give you that. but seriously, why are so many so hard on someone who needs help. There's obviously a bunch of ppl out there who knew the answer to this semi-programming-related question. If stackoverflow becomes some sort of elitist place where only this but not that can be discussed, then it's on its way out. Think about it. – Adergaard Oct 28 '09 at 20:08
    
Would this be a central store or just a client? – Matthew Whited Oct 28 '09 at 20:08
    
@Matthew Whited: well, in general I like to have a central repo where I know it won't disappear if I accidently set the building on fire and lose the hand held, laptop or home server. So central store is a must, even though I guess GIT really has no "central", it's simply where you did push or pull the latest. – Adergaard Oct 28 '09 at 20:11
    
Currently most svn questions are on SO, not SF, so I'd consider this relevant. – Ether Oct 28 '09 at 20:12

Subversion will require you to run either the svnserve daemon or mod_webdav in Apache to access your repositories. If you are looking to keep things to a minimum, you can set up svnserve to run as an inetd service (this is how I run a Subversion server on a little linux laptop in the basement) or using svn+ssh. Note that in all cases, a daemon is required to accept the incoming request, but you maybe able to piggyback on an existing service.

GIT can be used without a daemon of any kind, if you simply plan to use file sharing to synchronize your repositories. This isn't an ideal setup for a large development group, but it is workable if you are really constrained.

If one of these sounds better than the other, let me know and I can elaborate further.

share|improve this answer
    
superb. thanks for a fast answer. – Adergaard Oct 28 '09 at 20:00
2  
Subversion can run in a serverless mode like git does, look at svn+ssh repo designations. – Jim Zajkowski Oct 28 '09 at 20:01
    
Subversion doesn't require daemon if you go svn+ssh – Arkaitz Jimenez Oct 28 '09 at 20:01

Don't know for git, but for svn: you have multiple options.

If you use svnserve yes, it will have a running process. If you use svn+ssh protocol the svn process will only get created when needed, and not leave a permanent process running. If you already have an apache httpd running you can also let that one deliver svn content, in which case you have obviously the apache footprint.

share|improve this answer
    
With git you have the same mode as svn+ssh, it works basically the same using the opened ssh connection to pipe the protocol. – Arkaitz Jimenez Oct 28 '09 at 20:08
1  
In this case, SVN doesn't need a resident process, but a daemon is still required (sshd) to accept the request. – jheddings Oct 28 '09 at 20:10

Actually, subversion allows you to run without memory footprint, through ssh, will execute svnserve only for the moment you are commiting.

share|improve this answer
    
It sounds like the server is very constrained... I didn't want to assume sshd was running. If it isn't that will have to be added, in which case, a daemon is required to access SVN. – jheddings Oct 28 '09 at 20:11
2  
If you can't run sshd then you have a really tiny machine, and if that's the case, surely svnserve or git will blow the doors off. – Jim Zajkowski Oct 29 '09 at 21:28

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.