Where to host client repositories?
Tim Case
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?
Jonathan Younger
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:
http://blog.roundhaus.com/pages/screenshots
The service provides hosted subversion repositories with continuous
integration, changeset notifications, code browser, etc.
I'm looking for serious testers so if you are interested in joining
the private beta please email me off-list: jona...@daikini.com
Thanks,
-Jonathan
Steven R. Baker
> 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
Damien McKenna
> 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.
--
Damien McKenna - Husband, father, geek.
dam...@mc-kenna.com - http://www.mc-kenna.com/
Robby Russell
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
www.planetargon.com
www.robbyonrails.com
+1 503 445 2457
+1 877 55 ARGON [toll free]
+1 815 642 4068 [fax]
Robert Dempsey
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.
Robert Dempsey
Wynn
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
Josh Knowles
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.
--
Josh Knowles
joshk...@gmail.com
http://joshknowles.com
Damien McKenna
> 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?
/me starts to ponder a presentation for ORUG...
gregory...@gmail.com
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.
Hope this helps.
Greg
http://www.carbon8.us
http://www.busyashell.com
Drew Blas
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).
Rowan Hick
reasonably priced (I'm sure there's other services cheaper out there)
hosted svn, websvn, trac over https. Per account you can setup
multiple respositories, user access etc etc. With my one major client
I give him access incase I get hit by a bus - he's never accessed it
and assuming the bus never comes never will..
Been using it for over a year now, with one near miss - as always
never trust an offsite service, always keep backups !
--
Rowan Hick
web: http://work.rowanhick.com
skype: rowanthenerd
On Jun 7, 2:02 pm, Tim Case <tcrai...@gmail.com> wrote: