I have a client who's host doesn't allow shell access. Is there any multi-user revision control system that can work in that situation (on linux)? He's reluctant to switch hosts.
A:
Sure, SVN can have multiple users and multiple repositories. Depending of course on whether your host is willing to install it. If that doesn't work, maybe you'd consider hosting your version control somewhere else?
Kevin Laity
2009-03-09 14:15:25
+2
A:
Yes, because you don't do development directly on the production server! The content of your production server is just a view of your source repository, which is kept elsewhere so that work can be done on a separate dev server. This way, a stupid mistake on the dev server won't hose your production system. If that means doing a manual checkout to transfer the files, so be it.
Joel Coehoorn
2009-03-09 14:15:48
You could do everything on the same shared host, as long as your devevelopment work was done on a different subdomain. Keep your config files different so you're accesssing a dev database and it all works out pretty good.
Kibbee
2009-03-09 14:18:10
That's still a bad idea, imo. What happens when you have a brain-dead moment where you forget to increment your counter in a while loop on your dev system and it runs away with the cpu? Something like that happens to everybody now and then, and you want those mistakes isolated from production.
Joel Coehoorn
2009-03-09 14:20:49
The problem is that the repository has grown huge because of a lot of large, uploaded files, so synchronizing from testing to prod will be a big PITA. Maybe there's a way to not include that folder in the repo or something.
sprugman
2009-03-09 15:08:37
@sprugman User-uploaded files shouldn't be versioned with your code. That's user data. You back it up on tape.
Joel Coehoorn
2010-02-12 14:05:31
A:
Do you mean that you want to store your version control repository on the host and then access it from multiple clients? If yes, then all modern version control systems can work like that.
anon
2009-03-09 14:18:50
+2
A:
Not the answer you're looking for, but get a better hosting provider. Is there something special your hosting provider is doing for you that makes you want to put up with no shell access, or even not just preinstalling SVN for you? There's a ton of really good hosts for really cheap that will give you SVN already installed, and shell access.
Kibbee
2009-03-09 14:19:28
I had a bad host about 4 years back. I was also reluctant to switch. I understand the problem. When everything it "working" with one host, you don't want to go through the trouble of switching.
Kibbee
2009-03-09 15:40:57
However, it was worth it. With a properly planned migration, along with having both accounts open for a month to make sure the switch goes smoothly, there really isn't that many problems. Plus you'll save yourself a lot of headaches in the long run.
Kibbee
2009-03-09 15:41:54
A:
I've been looking for the same thing, I have a no-shell-access hosting provider with no included source control and don't want to change.
Currently, I'm using git. But instead of using git push to update the remote repository, I use a script and FTP to update the server's copy.
git pull works normally from any client, if the ftp git directory is accessible over http.
git push replacement:
git update-server-info
perl ftpsync.pl -v .git ftp://ftp.example.com/gitrepo/project.git
[email protected] ftppasswd=*
That's using ftpsync, from the Sourceforge ftpsync page. It's an imperfect replacement for git's push, it mirrors the local repo, instead of merging it with the remote, so make sure the local repo is up to date with git pull first.
git-ftp purports to do the same thing. Github's git-ftp page. Probably works better than ftpsync, because it's designed for the purpose, but I haven't tried it.
davenpcj
2010-06-06 22:41:01