I recently created a dev environment for a new client where they got an account with Rimuhosting and I built a complete dev environment there including installing a subversion repository. The idea I had was that the client gets their own server account and is in charge of the holding of their code.
Now, I'm wondering that because of the work necessary to get a server up, what's the difference if I just setup a server for all my clients and host all the code there while giving them accounts to the Subversion repository.
What's the protocol for this? What are you guys doing?
I don't want this to sound too advertisey but I've developed such a service that may fit your needs. It's still in private beta right now but you can checkout some screenshots here:
> I recently created a dev environment for a new client where they got > an account with Rimuhosting and I built a complete dev environment > there including installing a subversion repository. The idea I had > was that the client gets their own server account and is in charge of > the holding of their code.
> Now, I'm wondering that because of the work necessary to get a server > up, what's the difference if I just setup a server for all my clients > and host all the code there while giving them accounts to the > Subversion repository.
> What's the protocol for this? What are you guys doing?
> Now, I'm wondering that because of the work necessary to get a server > up, what's the difference if I just setup a server for all my clients > and host all the code there while giving them accounts to the > Subversion repository.
This is what I'm moving towards, and I'm making it policy that the source code isn't the client's business until they've paid for it. Two situations in particular have prompted this move. In one case, the client watched checkins, and when I made fewer commits than the previous week, they wanted a discount on the bill for that week. In another more recent case, the client actually started committing code and I wound up spending more time fixing and cleaning up his mess than actually writing code.
I've also had one situation where it came in handy to have the keys to the production server when the client decided to delay payment by a few weeks.
> What's the protocol for this? What are you guys doing?
Currently, for hosts that don't have their on SVN server I host the project locally via Apache & SSL. Combining it with Redmine gives a great combination as you can easily see from the Web interface all of the changes as they happen and automatically link them to issues. Good stuff. Of course what would be even better would be for Redmine to manage access to the repository with full permissions management, but the current system works well as-is.
>> Now, I'm wondering that because of the work necessary to get a server >> up, what's the difference if I just setup a server for all my clients >> and host all the code there while giving them accounts to the >> Subversion repository.
> This is what I'm moving towards, and I'm making it policy that the > source code isn't the client's business until they've paid for it. > Two situations in particular have prompted this move. In one case, > the client watched checkins, and when I made fewer commits than the > previous week, they wanted a discount on the bill for that week. In > another more recent case, the client actually started committing code > and I wound up spending more time fixing and cleaning up his mess than > actually writing code.
> I've also had one situation where it came in handy to have the keys to > the production server when the client decided to delay payment by a > few weeks.
> -Steven
In general, our clients don't really pay attention to the commits... in fact, if they did, they'd probably be shocked by how many commits there were. ;-)
Since we break things up into small iterations of work, we only give clients what they've paid for, which means that we take advantage of subversion branches. They can peak in at anytime to branches they've paid (in full) for, but since we're discussing the project at a high- level (user goals, interaction, and business goals...) the development is generally behind the scenes.
We also host the subversion repositories on our own servers, which keeps things in our possession until payment is received.
Anyhow, that's what we're doing at PLANET ARGON... and with all these new svn browsers, I'm keeping my eye out for one that we can host on our own servers.
Robby
-- Robby Russell Founder and Executive Director
PLANET ARGON, LLC Ruby on Rails Development, Consulting & Hosting
At ADS we use Unfuddle.com a majority of the time. Unfuddle is like a BaseCamp/Trac combo. We go this route if the client is on an on-going contract (i.e. they pay in advance or on a regular basis). Otherwise, we set up (and charge the client for) a development server that they have no access too aside from testing out the app (clicky clicky). I agree with everyone, and have it in our contract, that a client does not own any code until they pay for it. That is non-negotiable. If you can maintain as much control as possible do so. For us, it depends on the contract we have with the client. Using Unfuddle is great if they are more technically savvy. With some clients, even if they have full control over the svn repos and the servers, they have no idea and no real drive to do a checkout themselves and, if necessary, ask for a zipped copy of the code.
We, too use Unfuddle and with their recent upgrade to allow multiple projects per account, it's been a perfect fit for us. The access control is pretty granular and you can determine what source control access (if any) the client has.
If they just had a wiki, our portal proliferation would be solved ;-)
Wynn Netherland Bit Wrangler, Geek Herder Praexis www.praexis.com
On Jun 8, 8:41 am, Robert Dempsey <robertonra...@gmail.com> wrote:
> At ADS we use Unfuddle.com a majority of the time. Unfuddle is like a > BaseCamp/Trac combo. We go this route if the client is on an on-going > contract (i.e. they pay in advance or on a regular basis). Otherwise, > we set up (and charge the client for) a development server that they > have no access too aside from testing out the app (clicky clicky). I > agree with everyone, and have it in our contract, that a client does > not own any code until they pay for it. That is non-negotiable. If you > can maintain as much control as possible do so. For us, it depends on > the contract we have with the client. Using Unfuddle is great if they > are more technically savvy. With some clients, even if they have full > control over the svn repos and the servers, they have no idea and no > real drive to do a checkout themselves and, if necessary, ask for a > zipped copy of the code.
> I recently created a dev environment for a new client where they got > an account with Rimuhosting and I built a complete dev environment > there including installing a subversion repository. The idea I had > was that the client gets their own server account and is in charge of > the holding of their code.
> Now, I'm wondering that because of the work necessary to get a server > up, what's the difference if I just setup a server for all my clients > and host all the code there while giving them accounts to the > Subversion repository.
> What's the protocol for this? What are you guys doing?
Check out http://www.jumpbox.com/tracsubversion-development-jumpbox/. These guys have wrapped up SVN & Trac into a nice little VM that runs on parallels, xen and vmware. I'm been considering bringing up an instance of this for each client project, then at the end burning the VM to a dvd and shipping it to the client as a deliverable.
> At ADS we use Unfuddle.com a majority of the time. Unfuddle is like a > BaseCamp/Trac combo.
Something I've been wondering is why more people don't use Redmine (http://www.redmine.org/)? It has the trac-like features, some additional content management options, and is written in Ruby on Rails - what more could you want?
We are hosting svn at springloops.com which allows me to setup users for each developer and has a really nice logging system. I don't give access to the client until the final bill is paid. If they want, I can copy the logs from springloops and send them to the client, but no code until it's paid for. That's just too risky. Springloops also has, what looks to be a decent deploy script built in. I've never used it since we use capistrano, but for any php devs, it might be good.
> I recently created a dev environment for a new client where they got > an account with Rimuhosting and I built a complete dev environment > there including installing a subversion repository. The idea I had > was that the client gets their own server account and is in charge of > the holding of their code.
> Now, I'm wondering that because of the work necessary to get a server > up, what's the difference if I just setup a server for all my clients > and host all the code there while giving them accounts to the > Subversion repository.
> What's the protocol for this? What are you guys doing?
We run our own private development servers. We do not give repository access to clients, but instead post a fairly regular (usually agreed in advance to be weekly or bi-weekly) 'psudo-production' or beta- version of the code for them to look at and play with. Basically, anytime we do a tag of the trunk, we zip it up, send them the source, and then put it up for them to play with. They've always got the [nearly] latest source and can easily gauge our progress, but can't interfere with our operation or criticize our methods.
The key is that YOUR job is managing the source code. That's what programming is all about, so those aren't details that the clients are privy to (and, in every client I've ever worked with, they didn't WANT to have up to the minute access to what's going on).
